fmt.Sprintf("%.2f") 四舍五入不准，是因为它基于 IEEE 754 浮点数的近似存储值（如 2.135 实际存为 2.13499999999999979）进行银行家舍入，而非原始十进制字面量；金融等需确定性舍入场景应使用 decimal.Decimal 或整数缩放法。
fmt.Sprintf("%.2f") 为什么有时四舍五入不对？
它不是“算错”，而是先按 IEEE-754 存储值做四舍五入，而那个存储值本身可能就比你写的字面量略小。比如 2.135 在 float64 中实际存的是 2.13499999999999979，fmt.Sprintf("%.2f", 2.135) 自然输出 "2.13"。
这种现象在以 5 结尾的十进制数上高频出现（如 1.005、3.145），本质是二进制浮点无法精确表达多数十进制小数。
- 它用的是“银行家舍入”（
round half to even），不是传统四舍五入； - 仅适用于最终展示，不能用于中间计算——字符串来回转换会掩盖误差但不消除；
- 若需严格按十进制规则舍入（如财务场景），必须换用十进制类型，比如
shopspring/decimal。
math.Round(x / 0.01) * 0.01 为什么还是不准？
因为 0.01 本身在 float64 中就是近似值（实际是 0.010000000000000002），除法放大了这个误差。哪怕 math.Round 正确，输入值已经偏了。
典型失败案例：math.Round(2.135 / 0.01) * 0.01 → 先算 2.135 / 0.01 ≈ 213.49999999999997 → math.Round 得 213 → 再乘回得 2.13。
立即学习“go语言免费学习笔记（深入）”；
- 所有基于
float64的乘除 +math.Round组合，都逃不开底层表示误差； - 精度要求 ≤ 2 位小数且无累积计算时，可接受；超过 2 位或涉及多次运算，风险陡增；
- 若坚持用原生类型，应改用整数缩放：先转成整数分（如金额 × 100），再整数运算，最后除回——这是唯一可靠的
float64替代方案。
big.Float.SetPrec(n) 设置多少才够用？
big.Float 的精度单位是二进制位，不是十进制位。设 .SetPrec(64) 并不等于 “支持 17 位十进制小数”，而是约等于 float64 精度——根本没提升。
要安全保留 d 位十进制小数，推荐公式：prec = ⌈d × log₂(10)⌉ ≈ d × 3.322。例如保留 10 位小数，至少设 .SetPrec(34)；金融常用 28 位十进制（对应 ISO 4217），建议 .SetPrec(93) 或更高。
- 每次运算（加减乘除）都可能损失精度，必须全程保持足够
prec，不能只在初始化设； -
SetMode必须统一，混用big.ToZero和big.ToNearestEven会导致结果不可复现； -
Text('g', 20)显示位数 ≠ 实际精度，输出再多位也补不回内部丢掉的比特。
shopspring/decimal.Round() 的三种模式怎么选？
decimal 是十进制定点数，所有舍入都严格按十进制规则执行，没有二进制误差。它的 Round() 方法接受明确的舍入模式参数：
-
decimal.ROUND_HALF_UP：传统四舍五入（1.235 → 1.24）； -
decimal.ROUND_DOWN：直接截断（1.239 → 1.23），适合手续费计算； -
decimal.ROUND_UP：无条件进一（1.231 → 1.24），适合税费下限控制。
注意：decimal 默认构造不带精度上下文，必须显式调用 decimal.NewFromFloatWithExponent 或用 decimal.RequireDecimal 控制小数位数，否则从 float64 构造时仍会继承原始误差。
真正难的不是选哪个模式，而是确保整个数据流——从数据库读取、HTTP 解析、中间计算到写回——全程不经过 float64。只要有一处 float64 插入，前面所有努力就归零。
