decimal.NewFromFloat不能直接用，因为float64输入本身已失真，它只是将错误值转为decimal，无法恢复精度；应优先使用NewFromString或数据库直映射。
decimal.NewFromFloat 为什么不能直接用？
因为 float64 本身已经失真，NewFromFloat 只是把一个“错的值”转成 decimal.Decimal，后续所有计算都基于这个错误起点。比如 0.1 + 0.2 在 float64 中实际是 0.30000000000000004，用 NewFromFloat(0.1) 得到的 decimal 值就是这个近似值，不是真正的 0.1。
更安全的做法是：
- 前端传来的金额字符串，直接用
NewFromString("129.99") - 数据库读出的
DECIMAL字段（如 MySQL 的DECIMAL(20,8)），GORM 会自动映射为decimal.Decimal，无需中间转 float - 必须从 float 转时，先转字符串再转 decimal：
decimal.NewFromString(strconv.FormatFloat(x, 'f', -1, 64))，但仅限调试或兼容旧逻辑
除法结果位数怎么控制？
Div 默认保留最多 16 位小数，且使用银行家舍入（round half to even），容易和业务预期不符。例如税率计算、分账比例等场景，常需明确指定精度和舍入方式。
正确做法是用 DivRound：
立即学习“go语言免费学习笔记（深入）”；
-
a.DivRound(b, 2)→ 结果保留 2 位小数，四舍五入 -
a.DivRound(b, 0).Truncate(0)→ 先四舍五入到整数，再截断（避免 .0） - 若需向上取整（如运费计费），用
a.Div(b).RoundCeil(n) - 注意：
DivRound的n是小数点后位数，不是总位数
StringFixed 和 Round 的区别在哪？
Round(n) 改变 decimal 的内部值（返回新实例），影响后续所有运算；StringFixed(n) 只是格式化输出，不改变原始值，且强制补零、自动四舍五入。
典型误用：
- 用
d.Round(2).String()→ 输出可能为"123.4"（缺零），不符合金融显示规范 - 用
d.StringFixed(2)→ 总是"123.40"，适合 API 返回或日志记录 - 用
d.StringFixed(0)处理整元金额，比IntPart()更安全（后者丢弃小数部分但不四舍五入）
GORM 中 decimal 字段为什么不能加 sql:"type:decimal" 标签？
加了也没用——sql:"type:decimal" 只影响建表语句，而 Go 层变量仍是 float64，运算仍在二进制浮点世界里进行。真正起作用的是类型本身是否实现了 driver.Valuer 和 sql.Scanner。
shopspring/decimal.Decimal 已内置这两个接口，所以只需：
- Struct 字段声明为
decimal.Decimal - 配合数据库列定义（如 MySQL 的
DECIMAL(20,8)） - 迁移时确保列类型匹配，否则 GORM 会静默截断或报错
- 不要混用
float64和decimal.Decimal做运算，哪怕只在一行里写d.Add(decimal.NewFromFloat(x))，x 的误差就已引入
最易被忽略的一点：JSON 序列化时，decimal.Decimal 默认输出字符串（如 "123.45"），这反而是优点——避免前端 JS 再次解析 float 出错。但如果你依赖 json.Number 或自定义 marshaler，得额外确认行为一致性。
