报表精度问题源于数据源头和计算方式，须用 decimal.Decimal 替代 float64 处理金额等需人类可读精度的字段，从字符串初始化、全程高精度运算、导出前统一格式化。
报表精度不是格式化问题，而是数据源头和计算方式问题。直接对 float64 做统计再格式化，哪怕显示“2.50”，底层值仍是 2.4999999999999996——后续再加减、比较、导出 CSV，误差立刻暴露。
用 decimal.Decimal 替代 float64 做原始汇总
所有涉及金额、百分比、权重、汇率等需“人类可读精度”的字段，在定义结构体时就该用高精度类型：
- 别用
type ReportItem struct { Amount float64 }，改用import "github.com/shopspring/decimal"+Amount decimal.Decimal - 初始化必须从字符串或整数进：✅
decimal.NewFromFloat(2.55)（内部会转字符串再解析）或更稳的 ✅decimal.RequireFromString("2.55")；❌ 避免decimal.NewFromFloat(0.1 + 0.2)（传入前已失真） - 汇总操作全部走
.Add()/.Mul()/.Div()方法，不参与任何原生浮点运算 - 最终导出前再调
.Round(2).String()控制小数位，而非先 round 再存为 float64
fmt.Sprintf 和 strconv.FormatFloat 的精度陷阱
如果因历史原因无法替换底层类型，至少避免在汇总后才格式化：
-
fmt.Sprintf("%.2f", x)是四舍五入，但x本身可能已是失真值（如2.555实际存为2.5549999999999997→ 输出"2.55"） -
strconv.FormatFloat(x, 'f', 2, 64)行为相同，且第三个参数为-1时仅去尾零，不解决四舍五入逻辑缺陷 - 若必须用字符串截断（如日志打点），先用
math.Round(x*100) / 100预处理，但注意：这仍基于二进制浮点数，math.Round对2.555 * 100可能返回255.0而非256.0
报表导出时的写入控制要点
即使数值正确，文件写入环节也常丢精度：
- 写 CSV 时别用
fmt.Fprintf(w, "%.2f", d)—— 动词%.2f会强制补零，但若原始值是整数（如5.0），你可能想要"5"而非"5.00"；此时应统一走d.String()或d.Round(2).String() - 写入文件前务必检查
os.Create返回的err，空文件或内容缺失八成是 open 失败后忽略错误继续写 - 并发生成多个报表文件时，确保每个
*os.File独立打开关闭；共用一个io.Writer且未加锁会导致内容错乱
真正难的不是“怎么让数字看起来对”，而是让每一步中间值都保持可预期的十进制语义。一旦开始混用 float64 和字符串格式化，就等于把精度控制权交给了 IEEE 754 和 fmt 包的实现细节——而这两者，都不保证你的业务小数规则。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
