math.sqrt 返回 nan 是因输入负数，符合 ieee 754 标准，并非 bug；常见于判别式 Δ = b² − 4ac
math.Sqrt只接受非负float64，传负数不 panic，但返回NaN；整数必须显式转float64，否则编译失败——这是最常踩的两个坑。math.Sqrt 为什么突然返回 NaN？
不是 bug，是 IEEE 754 标准行为：
math.Sqrt(-1.0)必然返回NaN，Go 不做额外校验，也不报错。常见于：
- 两点距离公式中中间值
b*b - 4*a*c为负（判别式 Δ- 用户输入未过滤，比如字符串解析后得到负浮点数
- 多步浮点计算累积误差导致本该 ≥ 0 的值变成 -0.0000000001
检测方式只有两种：
math.IsNaN(result)或提前判断if x 。别等它“看起来不对”再查——<code>NaN会静默污染后续所有计算（比如NaN + 1 == NaN）。int 或 int64 能直接传给 math.Sqrt 吗？
不能。Go 没有隐式类型转换，
math.Sqrt签名严格是func Sqrt(x float64) float64。
math.Sqrt(16)→ 编译错误：cannot use 16 (type int) as type float64- 正确写法：
math.Sqrt(float64(16))- 对
int64同理：math.Sqrt(float64(myInt64))，但注意：超过2^53的整数转float64会丢失精度如果原始数据是
float32，别写float64(f32)—— 虽然合法，但易被误读为“强制升精度”，其实只是类型转换；明确写成float64(f32)更安全。想求整数平方根（比如 floor(√n)），能用 int(math.Sqrt(x)) 吗？
边界情况下会翻车。例如
math.Sqrt(25)理论上是5.0，但受底层实现或中间计算影响，可能得4.999999999999999，int()截断后变4。
- 临时缓解：
int(math.Sqrt(float64(x)) + 1e-9)- 更稳：
int(math.Floor(math.Sqrt(float64(x)) + 1e-12))- 但真要精确整数开方（尤其
uint64场景），别依赖浮点——用二分查找或bits.Len64配合牛顿迭代，避免精度陷阱性能上，
math.Sqrt本身极快（通常编译为 CPU 指令），拖慢你程序的往往不是它，而是前后那几行类型转换和容错逻辑。需要高精度（如 50 位小数）平方根怎么办？
math.Sqrt是 IEEE 754 double 精度，约 15–17 位有效数字。超出这个范围，误差不可控。
math/big.Rat不支持开方，且从float64构造会立刻引入精度损失- 标准库无内置高精度 sqrt；必须手动实现，推荐“逐位减法法”（Digit-by-Digit），它不依赖初始猜测，每步生成一位十进制结果，天然支持任意精度截断
- 若只是偶尔需要，可考虑调用外部高精度库（如
github.com/shopspring/decimal），但它内部仍基于浮点模拟，非真正任意精度真正难的从来不是调用函数，而是想清楚：你要的是“快”，还是“准”；是“近似结果”，还是“可验证的整数解”。选错路径，后面补救成本远高于一开始多想半秒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
