float32转float64本身无精度损失，但strconv.ParseFloat(s, 32)会在解析时截断精度（仅保留约7位十进制有效数字），再转float64也无法恢复；应始终用ParseFloat(s, 64)解析字符串，再按需转float32。
float32 转 float64 本身不丢失精度，但 parse 时选错 bitSize 会丢
直接用 float64(x) 转换一个已有的 float32 变量，是安全的——它只是把 32 位尾数“无损扩展”到 64 位，高位补零，数值完全不变。真正出问题的是字符串解析阶段：strconv.ParseFloat(s, 32) 这一步就已截断原始字符串的精度，再转 float64 也救不回来。
- 错误写法：
f, err := strconv.ParseFloat(s, 32); f64 := float64(f)→ 原始小数第 8 位起全丢 - 正确写法：
f64, err := strconv.ParseFloat(s, 64)→ 得到最接近该十进制数的float64值（约 17 位有效十进制位） - 若你最终只需要
float32，也应先按 64 位解析，再显式转：float32(strconv.ParseFloat(s, 64))
ParseFloat(s, 64) 是唯一推荐的字符串转浮点方式
别用 fmt.Sscanf 或正则+格式化再解析，它们要么不校验输入完整性，要么引入额外误差和性能开销。
-
"3.14abc"→Sscanf静默成功，只读前缀；ParseFloat明确返回strconv.ErrSyntax -
" 3.14 "→ParseFloat默认失败（除非你先strings.TrimSpace），而Sscanf会跳过空格 - 基准测试显示，
Sscanf比ParseFloat慢 3–5 倍，且 Go 1.20+ 对 Unicode 数字行为不稳定
全角空格、BOM、中文逗号这些字符会让 ParseFloat 直接失败
strings.TrimSpace 只清 ASCII 空格（' ', '\t', '\n' 等），对 \u3000（全角空格）、UTF-8 BOM（\xEF\xBB\xBF）、中文逗号 ， 完全无效。
- 常见报错：
strconv.ParseFloat: parsing " 3.14": invalid syntax（开头是全角空格） - 必须手动清洗：用
strings.Map或正则替换掉非 ASCII 空格，或用bytes.Trim+ 自定义判断 - 单位符号如
"123.45kg"、"¥56.78"也会触发ErrSyntax，需在调用ParseFloat前剥离
想控制“保留两位小数”不是靠字符串格式化再解析
用 fmt.Sprintf("%.2f", x) 再 ParseFloat，本质是做了一次 IEEE 默认舍入（to nearest, ties to even），不是数值截断，还多一次转换开销。
- 例如：
fmt.Sprintf("%.2f", 1.005)在某些 Go 版本中可能输出"1.00"或"1.01"，不可控 - 真要数值级四舍五入，用
math.Round(x*100) / 100；要向下/向上取整，用math.Floor/math.Ceil - 注意：
math.Round对负数是向远离零方向舍入，如math.Round(-1.5) == -2，若需向偶数舍入，得自己实现
真正容易被忽略的点在于：精度损失几乎从不来自 float32 → float64 这一赋值动作，而是发生在字符串解析的第一步——你传给 ParseFloat 的输入是否干净、bitSize 是否匹配最终用途。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
