Go语言原生无运行时浮点精度控制，float64精度由IEEE 754硬编码决定；所有“精度控制”实为输出截断或类型转换，非计算精度提升；真精度需全程避免float64，改用decimal或big.Float等高精度类型。
直接说结论：Go 语言原生 没有运行时可调的浮点数计算精度控制机制，float64 的精度由 IEEE 754 双精度标准硬编码决定（约 15–17 位十进制有效数字），所有“控制精度”的操作，本质都是在输出、显示、截断或换类型，而非改变计算过程本身的精度。
真正要解决精度问题，得先分清场景：是「展示用」「存储用」还是「参与后续计算」？选错路径，后面全白忙。
fmt.Sprintf 和 strconv.FormatFloat 的精度参数不是计算精度
很多人误以为 fmt.Sprintf("%.2f", x) 或 strconv.FormatFloat(x, 'f', 2, 64) 能让 x 变成“精确两位小数的数”，其实它们只生成字符串——底层 x 还是那个带误差的 float64。
常见错误现象：
• 用 %.2f 格式化 0.1 + 0.2 得到 "0.30"，但拿这个字符串再 ParseFloat 回来，仍是 0.30000000000000004（因为解析的是已失真的原始值）
• 传 -1 给 strconv.FormatFloat 看似“智能去零”，但它不四舍五入、也不修正误差，只是按当前二进制值转出最简十进制表示
math.Round 配合缩放无法真正修复浮点误差
例如写 roundTo2(x) = math.Round(x*100) / 100，看似四舍五入到两位小数，但问题在第一步：x * 100 本身可能就因二进制表示失真而偏移。比如 2.555 * 100 在 float64 中实际是 255.49999999999997，Round 后变成 255，最终结果是 2.55 而非预期的 2.56。
所以这类数学缩放只适用于误差容忍度高的场景（如 UI 显示），不能用于金融对账或条件判断。
需要真精度？必须换数据类型，且全程隔离 float64
以下三类方案按推荐强度排序：
• 金融/支付/对账场景：用 github.com/shopspring/decimal，从源头字符串初始化（decimal.RequireFromString("28860.000000001")），全程不经过 float64；
• 高精度科学计算：用 math/big.Float，但必须 SetString 初始化、显式 SetPrec(256)（注意单位是二进制位）、所有运算数 prec 对齐、避免任何 float64 混入；
• JSON/API 交互中保精度：字段加 json:",string" 标签，让数值以字符串形式传输，接收端再用 decimal 或 big.Float.SetString 解析
真正难的不是写对某一行格式化代码，而是从第一行输入开始，就拒绝把用户给的 "19.99" 先塞进 float64 ——那一步之后，精度就已经不可逆地丢了。
立即学习“go语言免费学习笔记（深入）”；
