用 decimal.Decimal 而非 float64 进行折扣计算可确保金融级精度，因其全程十进制运算，避免 IEEE 754 浮点误差；初始化须用字符串（如 decimal.RequireFromString），中间结果保持 decimal 类型，最终 Round(2) 得精确分位值。
用 float64 做折扣计算，哪怕只算一次，也可能导致金额对不上账——这不是“偶尔出错”，而是 IEEE 754 浮点表示的必然结果。
为什么 discount = price * (1 - rate) 会少一分钱？
因为 0.95、0.88 这类常见折扣率，在二进制中是无限循环小数。比如 0.95 存入 float64 后实际值是 0.94999999999999995559...。乘法一叠加，误差就暴露在最终分位上。
典型现象：
-
199.99 * 0.95理论应得189.9905，四舍五入到分应为189.99，但float64计算可能给出189.99049999999998，math.Round(x*100)/100后变成189.99（侥幸）或189.98（翻车） - 多次累加折扣后做汇总，误差还会放大
直接用 github.com/shopspring/decimal 处理折扣
这是金融级折扣计算最省心、最可靠的方式。它把数字当字符串或整数解析，全程十进制运算，不经过二进制浮点环节。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 初始化必须用
decimal.NewFromFloat64或更推荐的decimal.RequireFromString（避免浮点输入污染） - 折扣率统一转成
decimal.Decimal，别用0.95字面量 - 所有中间结果保持
decimal.Decimal类型，直到最后转成分单位整数存库或展示
示例：
price := decimal.RequireFromString("199.99")
rate := decimal.RequireFromString("0.95") // 注意：字符串传入
discounted := price.Mul(rate).Round(2) // Round(2) 是保留两位小数，非截断
// 结果是 189.99，绝对精准
如果只能用 float64，怎么降低翻车概率？
仅限内部统计、非资金场景。必须接受它「不是真精确」，只是“看起来像”。
关键约束：
- 所有输入价格、折扣率，必须是
float64能精确表示的数（即形如m / 2^k的有理数），现实中几乎无法保证 - 四舍五入函数必须用
math.Round(x*100 + 1e-9) / 100补偿浮点截断偏差（+1e-9是 hack，不是银弹） - 禁止链式计算：不要
price * 0.9 * 0.95，先合并折扣率再算一次
示例（不推荐，仅作对照）：
func roundToCent(x float64) float64 {
return math.Round(x*100+1e-9) / 100
}
final := roundToCent(199.99 * 0.95) // 得到 189.99（多数情况成立）
数据库和前后端如何配合不丢精度？
后端算准了没用，只要中间某环转成 float64 或 JSON 序列化，精度就没了。
必须对齐的三处：
- 数据库字段类型：用
DECIMAL(12,2)或NUMERIC，绝不用FLOAT/DOUBLE - Go struct tag：用
json:",string"把decimal.Decimal输出为字符串，防 JSON 解析器转成浮点 - 前端接收：接收到的是字符串（如
"189.99"），别用parseFloat再转回 number
最容易被忽略的是 JSON 序列化环节——decimal.Decimal 默认 Marshal 成数字，一发请求就退化回浮点。必须显式注册自定义 marshaler 或用 String() 手动转。
