ParseFloat("0.1") ≠ 0.1 是因 IEEE 754 下 0.1 为二进制无限循环小数，float64 只能存其近似值（如 0.10000000000000000555...），该误差从解析起始即存在，后续所有运算均基于此失真值；真正无损入口是 decimal.RequireFromString("0.1") 或 big.Float.SetString("0.1")。
直接用 strconv.ParseFloat 解析字符串得到的 float64，精度上限由 IEEE 754 决定，不是你能“控制”出来的；所谓“精度控制”，本质是选对输入源、选对解析路径、并在后续环节决定怎么用它——错在第一步（比如从 float64 构造再转 decimal），后面全白忙。
为什么 ParseFloat("0.1") ≠ 0.1？
这不是 Go 的 bug，而是所有遵循 IEEE 754 的语言共有的表示限制：0.1 在二进制下是无限循环小数，float64 只能存最接近它的近似值。你用 strconv.ParseFloat("0.1", 64) 得到的已经是失真值（0.10000000000000000555...），后续任何数学运算或格式化都基于这个误差起点。
- 验证方式：
fmt.Printf("%.60f", 0.1)或fmt.Printf("%.60f", strconv.ParseFloat("0.1", 64))输出一致 - 真正“无损”的入口只有
decimal.RequireFromString("0.1")或big.Float.SetString("0.1") -
ParseFloat的第二个参数必须是64（对应float64），传32会截断精度且不报错，但结果不可控
ParseFloat 后怎么保留指定小数位？
别在 float64 上硬“修”精度——它本就不该承载这种语义。若你只是需要输出或日志中显示固定小数位，应跳过二次解析，直接格式化：
- 写文件/日志：用
fmt.Fprintf(w, "%.6f", x)，但注意%.6f是四舍五入，不是截断 - 要“最多 6 位、尾随零省略”：先用
strconv.FormatFloat(x, 'f', -1, 64)，再写入 - 要“强制 6 位、补零”：用
strconv.FormatFloat(x, 'f', 6, 64)，比fmt.Sprintf更稳（不触发科学计数法） - 千万别：用
fmt.Sprintf("%.6f", x)→ParseFloat(..., 64)→ 再格式化，纯属自我污染
什么时候必须放弃 float64？
当你的业务逻辑依赖“精确等于”或“可逆计算”时，float64 就不该出现：
- 金融金额、库存数量、配置阈值（如
"timeout_ms": 300.5被存成300.49999999999994） - 需要和数据库 decimal 字段 round-trip 的场景（MySQL 的
DECIMAL(10,2)和 float64 不兼容） - 做等值判断：
a == b在 float64 中永远可疑，而decimal.Decimal.Equal(b)是安全的 - 正确做法：原始字符串直接进
decimal.RequireFromString(s)，全程不碰float64
big.Float 能替代 ParseFloat 吗？
能，但代价高、门槛严，且不能和 float64 混用：
- 初始化必须用
SetString("123.456")，SetFloat64(123.456)会把误差带进来 - 精度单位是二进制位（
prec），设prec=100≈ 30 位十进制有效数字，不是“小数点后 100 位” - 所有运算（
Add,Quo等）都需显式传参，返回值仍是*big.Float，不能直接参与+或== - 输出格式（如
f.Text('f', 10)）只影响显示，不提升内部精度
真正难的不是“怎么解析”，而是你得在读取原始数据那一刻就决定：这个数是“展示用的近似值”，还是“参与计算的精确量”。选错源头，后面所有精度操作都是徒劳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
