必须用strconv.ParseFloat，Go无隐式转换；float64("3.14")编译报错，fmt.Sscanf易静默丢弃后缀、性能差且Unicode行为不一致；bitSize填64最安全，填32仅影响解析精度但返回仍是float64；空格、单位、中文逗号等非法格式均返回ErrSyntax，须显式检查err。
必须用 strconv.ParseFloat，别想绕开它——Go 没有隐式转换，也没有“自动容错”模式，所有字符串转浮点数都得显式解析、显式检查错误。
为什么不能直接 float64("3.14") 或用 fmt.Sscanf 替代
编译器会直接报错：cannot convert "3.14" (untyped string constant) to float64。这不是语法糖缺失，是类型系统强制你面对输入质量。
fmt.Sscanf 看似能“凑合用”，但实际埋雷：
- 输入是
"123.45kg"，它只读前缀"123.45"就返回 nil error，后缀被静默丢弃 - 输入是
" 3.14 "（带空格），它能过；但ParseFloat会返回strconv.ErrSyntax—— 这反而是你想要的：明确区分“合法数值”和“带杂质字符串” - 基准测试显示，
Sscanf比ParseFloat慢 3–5 倍，且 Go 1.20+ 对 Unicode 数字字符行为不一致
ParseFloat 的 bitSize 参数到底怎么填
bitSize 不是“我要输出 float32 就填 32”，而是“我要求解析器按 float32 的精度语义去解析”，但返回值**永远是 float64**。
立即学习“go语言免费学习笔记（深入）”；
- 填
64：按 float64 精度解析，返回 float64 → 最常用、最安全 - 填
32：按 float32 精度解析（即先截断到 23 位有效尾数），再转成 float64 返回 → 会丢失精度，且无法还原原始 float32 值 - 如果最终要存为
float32，正确写法是：float32(strconv.ParseFloat(s, 64))，而不是strconv.ParseFloat(s, 32)
空字符串、中文逗号、单位符号都会让 ParseFloat 失败
它只认标准 ASCII 浮点格式："123.45"、"-0.001"、"1e2"、"Inf"、"NaN" 都合法；其余一律返回 strconv.ErrSyntax。
-
""、" "、"123,45"（英文逗号）、"123.45元"、"123.45kg"→ 全部失败 - 若需容忍前后空格，先调
strings.TrimSpace；但它不处理全角空格或 BOM，得自己判断 - 千万别写
if err != nil { f = 0 }—— 0 可能是有效业务值（比如温度、海拔、余额） - 线上故障 90% 来自忽略
err，不是函数不好用，是没写if err != nil分支
ParseFloat 解析后怎么控制小数位数（比如保留两位）
它本身不负责格式化，只负责“把字符串变成最接近的 IEEE754 值”。要四舍五入到两位小数，得在数值层面操作：
- 推荐用数学方法：
math.Round(f*100) / 100，避免字符串来回转换的性能与精度损耗 - 如果只是用于输出（如日志、API 响应），用
fmt.Sprintf("%.2f", f)更直观 - 如果输出后还要再解析回 float64，别用
Sprintf + ParseFloat组合——这等于做无意义的两次精度扰动 - 注意：
fmt.Sprintf("%.2f", 0.1+0.2)输出"0.30"，但底层仍是0.30000000000000004，这不是 bug，是 IEEE754 本质
真正难的从来不是“怎么写那行代码”，而是决定“空输入算错误还是默认值”“带单位字符串是前端修复还是后端容错”“精度截断发生在入库前还是展示前”——这些决策点，ParseFloat 从不替你做，它只冷静地告诉你：“这个字符串，按标准，它不是合法浮点字面量。”
