Go报表精度问题源于float64误差、时间聚合偏差及JSON序列化链路漂移；应统一用int64（如“分”）运算、显式时区处理、decimal库替代float64、模板预格式化、CSV字段加引号，全程控制精度。
Go 语言本身不内置报表统计能力，精度问题几乎都出在浮点数计算、时间聚合、整数截断或 JSON 序列化环节——不是“报表库不够强”，而是开发者没意识到 float64 在累加、平均、百分比场景下会悄悄累积误差，或没控制好 time.Time 的时区与截断粒度。
为什么 float64 算平均值会偏移？
Go 默认用 float64 做数值运算，但 IEEE 754 双精度无法精确表示很多十进制小数（如 0.1 + 0.2 != 0.3）。报表中常见的“总金额 × 税率”“日均订单量”“占比%”极易因此失真。
- 避免直接用
float64累加金额：改用整数单位（如“分”）+int64运算，最后除以 100 输出 - 需要小数位控制时，不用
fmt.Sprintf("%.2f", x)四舍五入显示——它只是格式化，不修正原始值；应使用math.Round(x*100) / 100或更稳妥的decimal库（如shopspring/decimal） - JSON 编码时，
float64字段可能被前端二次解析再计算，建议后端返回字符串（"amount": "199.99"）或整数单位，杜绝链路漂移
时间维度聚合如何避免跨天/跨月偏差？
报表按“天”“周”“月”分组时，time.Truncate 和 time.Date 行为差异极大。比如用 t.Truncate(24*time.Hour) 在夏令时切换日会错位 1 小时；用 time.Date(t.Year(), t.Month(), 1, 0, 0, 0, 0, t.Location()) 才真正代表“当月第一天零点”。
- 所有时间分组必须显式指定时区：
loc, _ := time.LoadLocation("Asia/Shanghai")，别依赖time.Local - “本周”不能简单用
t.AddDate(0,0,-7)，要用t.AddDate(0,0,-int(t.Weekday()))配合loc计算周一 - 数据库查询中，
GROUP BY DATE(created_at)是 MySQL 时区敏感操作，Go 层应统一转换为 UTC 后再传参，或强制用CONVERT_TZ
go-template 渲染报表时数字格式易踩的坑
html/template 和 text/template 不处理数值精度——它只原样输出变量值。你传 123.456789，它就输出全部位数，前端表格列宽一挤就变形，用户还误以为是计算错误。
立即学习“go语言免费学习笔记（深入）”；
- 模板里禁止直接写
{{.Amount}}，应预处理字段：定义结构体时用方法封装格式化逻辑，例如func (r Report) AmountStr() string { return decimal.NewFromFloat(r.Amount).Round(2).String() } - 若需动态精度（如配置“保留 1 位小数”），模板函数要接收参数：
{{.Amount | round 1}}，对应注册函数round = func(f float64, d int) string { ... } - 导出 CSV 时，字符串字段必须加双引号包裹，否则含逗号或换行的字段会破坏行列对齐——
fmt.Fprintf(w, "\"%s\",%s\n", name, amountStr)
最常被忽略的是：精度控制不是“最后加个四舍五入”就能解决的，它必须从数据读取、中间计算、序列化、模板渲染到导出文件，全程保持单位一致、时区明确、类型可控。任何一环用 float64 自由流转，报表就不可信。
