go 中 math.isnan 是唯一可靠的 nan 检测方式，因 nan != nan 是 ieee 754 规定，故不能用 == 或 != 判断；math.isnan 底层调用 cpu 指令，对非 nan 值均返回 false，且零开销。
Go 中 math.IsNaN 是唯一可靠的 NaN 检测方式
直接用 == 或 != 判断 NaN 一定失败——因为 NaN != NaN 是 IEEE 754 规定，Go 完全遵循。你写 if x == math.NaN() { ... } 永远进不去分支。
必须用标准库的 math.IsNaN 函数，它底层调用 CPU 的 ucomisd（x86）或等效指令，不依赖值比较。
-
math.IsNaN接收float64或float32（需显式转换），返回bool - 对
+Inf、-Inf、正常数都返回false，只对真正的 NaN 返回true - 不要自己写
x != x——虽然它在多数情况下有效，但 Go 编译器可能优化掉，且语义不清晰、不可维护
哪些运算会静默产出 NaN 而不 panic
Go 的浮点运算默认不 panic，出错就默默返回 NaN。最容易踩坑的是数学函数边界输入：
-
math.Sqrt(-1)→NaN -
math.Acos(2)、math.Asin(1.5)→NaN -
0.0 / 0.0、math.Inf(1) - math.Inf(1)→NaN -
math.Log(-1)、math.Log(0)→-Inf和-Inf，但math.Log(-0.0)也是NaN
注意：math.Pow(0, 0) 返回 1（符合 IEEE，不是 NaN），但 math.Pow(-1, 0.5) 是 NaN。
立即学习“go语言免费学习笔记（深入）”；
在关键路径上必须检查 NaN，不能靠日志兜底
一旦 NaN 进入后续计算，会像病毒一样传染：任何与 NaN 的算术运算结果仍是 NaN，而且 fmt.Printf 默认输出 NaN 字符串，容易被误认为“只是显示问题”。
- 金融计算、物理仿真、机器学习梯度更新等场景，一个 NaN 可能导致整批结果失效
- 不要只在入口或出口 log 一下；要在每个可能产生 NaN 的函数调用后立刻检查，例如：
result := math.Acos(x)<br>if math.IsNaN(result) {<br> return errors.New("invalid input: acos of out-of-range value")<br>} - 如果性能敏感，可考虑用
go:linkname直接调用runtime.nan()，但没必要——math.IsNaN几乎零开销
JSON 解析和 HTTP 请求体里的 NaN 会被静默丢弃
Go 的 encoding/json 默认拒绝 NaN：遇到 "NaN" 字符串会报错 json: invalid number literal；但如果你用了 UseNumber() 或自定义 UnmarshalJSON，又没做校验，NaN 就可能混进来。
- HTTP body 中若含
{"value": NaN}（非标准 JSON，但某些前端库会发），标准json.Unmarshal直接失败 - 更危险的是：用
json.Number解析后再转float64，如果原始字符串是"NaN"，会得到真正的NaN值，且无提示 - 建议在解析后统一过一遍
math.IsNaN，尤其当字段来自外部不可信源时
NaN 不是异常，它是合法的浮点状态；Go 不替你决定它是否可接受——该检查的地方，一行 if math.IsNaN(x) 就是底线。
