Go中用float64处理订单金额必然出错，因其二进制表示无法精确表达十进制小数（如0.1+0.2≠0.3），导致比较失败、显示异常、数据库偏差及对账错误；正确做法是用int64存“分”或shopspring/decimal库。
Go 中用 float64 处理订单金额会出事
直接用 float64 存订单金额，不是“可能出错”，而是“必然出错”。浮点数二进制表示无法精确表达很多十进制小数（比如 0.1 + 0.2 != 0.3），在加减、比较、数据库写入或对账时会暴露精度丢失。哪怕只做展示，前端渲染或日志打印也可能出现 99.99999999999999 这类值。
常见错误现象包括：if order.Amount == 19.99 判断失败；fmt.Printf("%.2f", total) 输出 19.989999999999998；与 MySQL 的 DECIMAL 字段交互后读回值偏差；聚合统计结果漂移。
- 正确做法是统一用整数单位（如“分”）存
int64，或使用专用库如shopspring/decimal - 若必须用小数逻辑，
shopspring/decimal.Decimal是目前最稳妥的选择——它基于整数实现，支持指定精度、四舍五入模式，且能准确比较和序列化 - 避免用
big.Float：它仍属浮点语义，不解决业务意义上的“精确十进制”问题
shopspring/decimal 的 RoundBanker 与 RoundHalfUp 区别
订单金额四舍五入必须明确策略，否则不同环境结果不一致。例如用户支付 19.995 元，该收 19.99 还是 20.00？银行常用“四舍六入五成双”（RoundBanker），而多数业务系统倾向“五入”（RoundHalfUp）。
shopspring/decimal 默认使用 RoundHalfUp，但需显式指定精度，否则 .Round() 不生效：
立即学习“go语言免费学习笔记（深入）”；
d := decimal.NewFromFloat(19.995) d.Round(2) // ❌ 无效：没指定 rounding mode，仍用默认的 RoundHalfUp，但调用方式不对 d.Round(2, decimal.RoundHalfUp) // ✅ 正确
- 入库前必须调用
.Round(2, decimal.RoundHalfUp)确保两位小数 - 涉及分润、手续费等多级计算时，中间步骤建议保留更多位（如 4 位），最后再 Round 到 2 位，避免累积误差
- 不要依赖 JSON 序列化自动截断：
decimal.Decimal默认序列化为字符串，但若误用json.Number或自定义 marshaler 转成 float，就退回陷阱
数据库字段类型与 Go struct 字段不匹配导致的静默截断
MySQL 建表用 DECIMAL(10,2)，但 Go struct 里写 Amount decimal.Decimal 并不保险。如果插入前没校验精度，超长值（如 123456789.123）会被 MySQL 自动截断为 123456789.12，且不报错——这是 MySQL 的 SQL Mode 问题，默认 STRICT_TRANS_TABLES 关闭时就会静默处理。
- 建表时加约束：
CONSTRAINT chk_amount CHECK (amount >= 0 AND amount - Go 层插入前主动校验：
if !amount.GreaterThanOrEqual(decimal.Zero) || amount.GreaterThan(maxAllowed) { return errors.New("invalid amount") } - 连接 MySQL 时启用严格模式：
parseTime=true&loc=Local&sql_mode='STRICT_TRANS_TABLES'，让超界直接报ERROR 1264 (22003): Out of range value - ORM 如 GORM v2 默认不校验 decimal 字段长度，需手动加
checktag 或用BeforeCreatehook 拦截
并发下单时金额校验与扣减的竞态风险
用户并发点击支付，后端若先查余额、再判断、再扣减，三步非原子操作，必然出现超卖。例如余额 100 元，两个请求同时读到 100，都判断“够付 99 元”，最终扣成 -98 元。
- 核心逻辑必须下推到数据库层：用
UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?，检查RowsAffected == 1 - 不要在 Go 层用
sync.Mutex锁用户 ID——分布式环境下无效，且锁粒度太粗影响吞吐 - 若涉及多账户（如优惠券+余额+积分），需用数据库事务 + 乐观锁（version 字段）或 SELECT FOR UPDATE，但注意死锁顺序
- 金额校验不能只靠前端或中间层传入的
total值，必须服务端按商品单价 × 数量实时重算，并比对订单快照
精度问题从来不在“怎么表示”，而在“谁负责在哪一步确保”。从输入解析、中间计算、持久化、再到下游对账，每个环节都要有明确的精度契约，而不是寄希望于某一层兜底。
