数据库float64精度问题本质源于字段类型、驱动解析和Go值接收三层失真，必须同步约束schema（用DECIMAL而非FLOAT）、driver（接收为string再转decimal）及绑定（用decimal.String()写入或int64存“分”）。
数据库读写时的 float64 精度问题，本质不是 Go 控制得了的——它卡在三处：数据库字段类型、驱动层解析逻辑、Go 值接收方式。你不能靠 fmt.Sprintf 或 math.Round 临时补救，必须从 schema、driver 配置、值绑定三个层面同步约束。
PostgreSQL/MySQL 中 float 类型字段本身就是精度陷阱
直接用 REAL（PostgreSQL）或 FLOAT（MySQL）存金额、比例、坐标等，等于主动放弃精度控制。这些类型底层映射到 IEEE 754 float32/float64，入库前就可能失真（比如 0.1 + 0.2 存进去就是 0.30000000000000004）。
- ✅ 正确做法：金额、税率、配置参数等十进制敏感数据，一律用
DECIMAL(p,s)或NUMERIC(p,s)，例如DECIMAL(19,4) - ⚠️ 注意：PostgreSQL 的
NUMERIC无精度丢失，但 MySQL 的DECIMAL在高并发写入时若未加事务隔离，仍可能因中间计算引入误差 - ❌ 别碰
FLOAT/DOUBLE字段——它们连SELECT x = 0.1这种简单判断都不可靠
database/sql 驱动默认把 DECIMAL 当 string 解析
多数驱动（如 lib/pq、go-sql-driver/mysql）为避免浮点失真，默认将数据库的 DECIMAL 列返回为 string，而非 float64。这是保护机制，但容易被忽略。
- 读取时若用
rows.Scan(&x)且x是float64，驱动会默默调strconv.ParseFloat—— 一次精度污染 - 正确做法：声明接收变量为
string，再交给decimal.Decimal处理：var amountStr string err := rows.Scan(&amountStr) if err != nil { return err } d := decimal.RequireFromString(amountStr) - 若坚持用 float64 接收，必须确认驱动已启用
parseTime=true且allowAllFiles=true等无关选项——不解决根本问题，还埋雷
写入时别用 float64 直接 Bind，先转 decimal 或 int64
用 db.Exec("INSERT ...", price) 把 float64 直接塞进 DECIMAL 字段，等于把失真值交由数据库二次 round——结果不可控（MySQL 可能截断，PostgreSQL 可能报错）。
- ✅ 安全路径一（推荐）：用
decimal.Decimal构造值，再调.String()写入：d := decimal.NewFromFloat(123.456).Round(2) _, err := db.Exec("INSERT INTO orders(amount) VALUES (?)", d.String()) - ✅ 安全路径二（更底层）：金额类全部按“分”存
INT，读写都用int64，彻底绕过小数： - ❌ 绝对避免：
db.Exec("...", math.Round(x*100)/100)——float64已失真，round 只是让错误看起来整齐
最常被跳过的环节是：没检查数据库字段定义是否真用了 DECIMAL，也没验证驱动是否真的返回了 string。这两步漏掉一个，后面所有精度控制都是假动作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
