最稳妥的浮点数格式化方式是 strconv.FormatFloat(x, 'f', -1, 64)，它避免 fmt.Printf 的隐式行为，自动省略尾随零且不四舍五入；需四舍五入时应先 math.Round 缩放再格式化。
用 fmt.Printf 输出时，%.Nf 是最常用但容易误用的方式
它强制保留 N 位小数并四舍五入，比如 fmt.Printf("%.2f", 3.14159) 输出 3.14，fmt.Printf("%.2f", 0.001) 输出 0.00——这在日志或配置中可能丢失原始量级信息。
常见错误包括：
- 对极小值（如
1e-6）用%.6f得到全零串，掩盖了非零事实 - 对大数（如
123456789.0）用%.6f输出超长字符串，破坏对齐或截断 - 混用
%g期望“智能精度”，却在1e12附近突然切到科学计数法，导致下游解析失败
若你只要快速调试、且数值范围可控，%.6f 没问题；但若需稳定输出（如写入 CSV、生成配置），建议跳过这层直接控制字符串。
真正可控的精度控制，靠 strconv.FormatFloat
它把 float64 转成字符串，不经过格式化动词中间层，避免隐式行为。关键参数是第三个：精度（prec）。
立即学习“go语言免费学习笔记（深入）”；
- 传正整数（如
2）→ 强制保留该位小数，末尾补零：strconv.FormatFloat(3.1, 'f', 2, 64)→"3.10" - 传
-1→ 自动省略所有尾随零，不四舍五入：strconv.FormatFloat(5.0, 'f', -1, 64)→"5"，strconv.FormatFloat(3.1400, 'f', -1, 64)→"3.14" -
bitSize必须是64（对应float64），传32会 panic
写入文件时推荐组合：strconv.FormatFloat(x, 'f', -1, 64) + fmt.Fprint(w, ...)，比 fmt.Fprintf(w, "%.6f", x) 少一次内存分配，也避开动词陷阱。
需要“最多 N 位小数且去零”？得先数学缩放再格式化
strconv.FormatFloat 的 -1 精度只去零，不四舍五入；正整数精度又强制补零。若你明确要“四舍五入到 4 位小数，再删尾零”，就得预处理：
- 先调
math.Round(x * 1e4) / 1e4（注意1e4是float64） - 再用
strconv.FormatFloat(rounded, 'f', -1, 64) - 别用
int(x*1e4+0.5)/1e4—— 浮点误差会导致0.29999999999999993这类结果
这个路径适合存储场景（如数据库字段要求固定小数位），但注意：缩放+取整不可逆，后续计算不能再用该字符串反推原始值。
写入文件时，格式化只是前半程，I/O 才是掉坑主力
即使字符串生成正确，fmt.Fprintf 报错或内容为空，大概率不是格式问题，而是 I/O 层没兜住：
-
os.Create返回nil文件句柄却忽略err→ 后续fmt.Fprintfpanic “invalid memory address” - 忘记
defer file.Close()→ 缓冲区未刷新，小文件内容根本没落盘 - 并发写同一
*os.File→ 不加锁会乱序，尤其用bufio.NewWriter时更隐蔽 - 拼 JSON 字段手动加引号：
"lat": " + strconv.FormatFloat(lat, 'f', -1, 64) + ","→ 推荐用json.Marshal或fmt.Fprintf(w, `"lat":%s`, s)避免引号/转义错位
真正难的从来不是“怎么让 3.14159 变成 3.14”，而是判断：这个值是给人看的（容忍四舍五入）、给机器读的（要求可逆）、还是参与下一步计算的（必须保持 float64 类型）。选错起点，后面每一步都在放大偏差。
