科学计数法转浮点数精度失控的根源在于混淆解析与展示阶段：ParseFloat解析即固定IEEE 754二进制表示，后续格式化无法恢复丢失的十进制精度；需根据场景选float64或big.Float，而非仅调整输出格式。
科学计数法字符串（如 "1.23e-5"）转成浮点数再格式化输出时，精度失控的根源不在“怎么转”，而在于你混淆了「解析阶段」和「展示阶段」——前者决定数值是否可逆，后者决定人眼是否易读。
ParseFloat 解析时就定下精度上限
用 strconv.ParseFloat("1.23e-5", 64) 得到的 float64 值，其二进制表示已固定。后续所有格式化操作都无法恢复被 IEEE 754 截断的十进制信息。比如 "0.1" 解析后实际是 0.10000000000000000555...，这不是 bug，是 float64 的物理限制。
- 必须传
64（不能写32），否则运行时 panic - 若原始字符串含非法字符（空格、逗号、
"1,000.0"），err非 nil，必须检查，不能忽略 - 支持
"1.23e-5"和"4.5E+2"，但不支持千分位或单位符号（如"1.23k"）
FormatFloat 的 'e'/'f'/'g' 动词行为差异
strconv.FormatFloat(f, 'e', -1, 64) 和 fmt.Sprintf("%.6e", f) 看似等价，实则关键区别在精度参数含义：
-
'e'：强制科学计数法，-1表示“最少必要位数”（省略尾随零），6表示“固定保留 6 位小数”（3.1415926e-3→"3.141593e-03"） -
'f'：强制定点小数，-1输出"0.00000123"，6输出"0.000001"（可能截断而非四舍五入） -
'g'：自动选'e'或'f'中更短者，但无法控制“最多 N 位小数”，且大数必切e形式（12345678.0→"1.23457e+07"）
写入文件时避免科学计数法乱入
直接用 fmt.Fprintf(w, "%.6f", x) 最简单，但要注意它不处理极小/极大值：当 x 是 1e-10 时，"0.000000" 就丢了全部有效数字。真正可控的做法是先转字符串再写：
立即学习“go语言免费学习笔记（深入）”；
- 用
strconv.FormatFloat(x, 'f', -1, 64)→ 得"0.00000123"（去零，但不缩放） - 若需“最多 6 位小数且去零”，得先数学缩放：
math.Round(x * 1e6) / 1e6，再调FormatFloat(..., 'f', -1, 64) - 文件未成功打开就写入 →
nil pointer dereference；忘记Close()→ 缓冲区内容不落盘；并发写同一文件 → 数据错乱
高精度场景必须绕开 float64
如果输入是 "1.2345678901234567890" 这类超长十进制字面量，又要求输出保持全部位数，float64 从第一步就失守。此时唯一出路是 big.Float：
- 必须用
new(big.Float).SetString("1.2345678901234567890")初始化，SetFloat64(1.2345678901234567890)没用 -
SetPrec(256)控制二进制精度，不是小数位数；要 30 位十进制精度，至少设prec = 100 - 输出仍需
f.Text('f', 30)控制显示位数，但底层精度由SetPrec决定
最常被忽略的一点：科学计数法字符串的“精度”问题，90% 出现在解析后立刻做比较或参与计算——这时候你其实需要的不是格式化，而是确认该用 float64 还是 big.Float，选错类型，后面所有格式化都是在给错误打补丁。
