在 Go 中处理货币时，若需对最小单位（如 1 分）进行精确除法（例如均分），直接使用 uint64 会导致整数截断（1/2 = 0）；而浮点类型会引入舍入误差。推荐使用 math/big.Rat——它以分数形式表示有理数，支持任意精度、零丢失的算术运算。
在 go 中处理货币时，若需对最小单位（如 1 分）进行精确除法（例如均分），直接使用 `uint64` 会导致整数截断（1/2 = 0）；而浮点类型会引入舍入误差。推荐使用 `math/big.rat`——它以分数形式表示有理数，支持任意精度、零丢失的算术运算。
在金融系统中，“1 分钱能否被公平拆分”看似边缘，实则是精度保障的关键测试用例。例如：将 1 美分三等分（$0.01 ÷ 3$），结果应为 $0.\overline{003}$ 美分（即 $1/3$ 分），而非 0（整数截断）或 0.003333333...（浮点近似）。此时，uint64（代表“分”的整数）和 float64 均不适用：
- uint64 是整数类型，1 / 3 结果为 0，信息永久丢失；
- float64 虽可表示小数，但二进制浮点无法精确表达十进制分数（如 0.01 本身已是近似值），多次运算后误差累积，违反金融计算的确定性要求。
✅ 正确方案：使用 math/big.Rat
big.Rat 将数值表示为分子/分母的有理数（如 1/100 表示 1 分，1/300 表示 1/3 分），所有运算（加、减、乘、除、比较）均保持数学精确性，且支持任意大小的整数分子与分母（受内存限制）。
以下是一个完整示例，演示如何用 big.Rat 精确拆分 1 分钱：
package main
import (
"fmt"
"math/big"
)
func main() {
// 以“分”为单位：1 分 = 1/100 美元 → 表示为 Rat(1, 100)
oneCent := new(big.Rat).SetFrac64(1, 100)
// 拆分为 3 份：1/100 ÷ 3 = 1/300
threeParts := new(big.Rat).Quo(oneCent, big.NewRat(3, 1))
// 输出为小数（用于展示，不用于计算）
fmt.Printf("1 分 ÷ 3 = %s 美元\n", threeParts.FloatString(6)) // → "0.003333"
// 验证精度：3 × (1/300) == 1/100？
check := new(big.Rat).Mul(threeParts, big.NewRat(3, 1))
fmt.Printf("验证: 3 × %s = %s → %t\n",
threeParts.FloatString(6),
check.FloatString(6),
check.Cmp(oneCent) == 0) // → true
}? 关键注意事项：
- 避免过早转为浮点：FloatString() 或 Float64() 仅用于显示或调试，不可用于后续计算，否则重蹈浮点陷阱；
- 格式化输出需按业务规则四舍五入：真实记账时，最终需按货币规范（如 USD 到分）做有理数舍入（如 Rat.SetFrac(...).Round(...)），big.Rat 提供 SetFrac64 和自定义舍入逻辑支持；
- 性能与内存权衡：big.Rat 运算比原生整数慢，内存占用更高，但对绝大多数金融应用（非高频微秒级交易）完全可接受；若性能极端敏感，可结合“固定小数位 int64 + 显式舍入策略”设计，但必须全程统一舍入规则（如银行家舍入）；
- 序列化友好：big.Rat 支持 MarshalText()/UnmarshalText()，可安全存入 JSON 或数据库（如 "1/300" 字符串），确保跨服务精度无损。
总结：当业务逻辑涉及货币的任意精度除法（如分润、利息日计、多边结算）、或需数学上可验证的确定性时，math/big.Rat 是 Go 生态中兼顾精度、正确性与可用性的首选。它不替代“以最小单位整数存储”的通用原则，而是为其提供可扩展的高精度补充能力——让“1 分能被公平地分成 7 份”不再是妥协，而是默认行为。
