math.Inf(1) 和 math.Inf(-1) 怎么用才不会误判
Go 的 math.Inf(1) 生成正无穷，math.Inf(-1) 是负无穷，但它们不是常量，不能直接写在 const 声明里；更关键的是，== 对无穷值的比较是合法的，但容易和浮点精度问题混淆。
- 别用
a == math.Inf(1)判定无穷——虽然语法对，但若a来自计算（比如除零），某些编译器或平台可能因优化导致行为不一致；应改用math.IsInf(a, 1) -
math.IsInf(x, 0)可同时匹配正负无穷；第三个参数传1或-1才做方向限定 - 注意：
math.Inf(0)是非法调用，会 panic，必须传1或-1 - 如果变量是
float32，记得先转成float64再传给math.IsInf，否则类型不匹配
math.NaN() 生成的值无法用 == 判断的原因
math.NaN() 返回一个 NaN 值，而根据 IEEE 754 标准，任何值（包括它自己）与 NaN 做 == 比较都返回 false。这是最常踩的坑——写 if x == math.NaN() 永远不成立。
- 必须用
math.IsNaN(x)判定，这是唯一可靠方式 -
math.NaN()每次调用返回的 bit pattern 不一定相同，所以也不能用reflect.DeepEqual或bytes.Equal比较两个 NaN - 从 JSON 解析来的
"null"或字符串不会自动变成 NaN；只有显式计算（如0.0/0.0）或调用math.NaN()才产生 NaN - 数据库驱动（如 pq、mysql）读取 NULL float 字段时，通常返回零值而非 NaN，需额外字段标记是否 NULL
在结构体 JSON 序列化中保留 NaN/Inf 的实际限制
标准库 encoding/json 默认把 NaN 和 Inf 当作无效值，序列化时直接报错 "invalid number"，不会输出 NaN 或 Infinity。
- 想让 JSON 输出
NaN，必须自定义MarshalJSON方法，并手动写入字节[]byte("NaN")；但多数前端 JS 环境不认这个，解析会失败 -
json.Encoder的SetEscapeHTML(false)对 NaN/Inf 无效，这不是转义问题，是规范层面禁止 - 更现实的做法：提前在业务层把 NaN/Inf 映射为特定字符串（如
"__NaN__"）或 null，并在反序列化时还原 - Gin、Echo 等框架的绑定默认不处理 Inf/NaN，收到含 Inf 的请求体时，
json.Unmarshal直接返回 error，需在中间件预检
性能敏感场景下 IsNaN / IsInf 的开销是否可忽略
这两个函数底层只是位运算检查指数域，没有函数调用栈开销，实测在现代 CPU 上单次耗时约 1–2 ns，比一次普通整数比较略高，但远低于一次 map 查找或内存分配。
立即学习“go语言免费学习笔记（深入）”；
- 不要为了“省一次调用”而用
x != x判 NaN——这虽符合标准，但可读性差，且 Go 编译器不保证所有优化路径下行为一致 - 避免在 tight loop 里反复调用
math.NaN()；它每次都是新分配，应提前提取为包级变量（如var NaN = math.NaN()） - 注意：Go 1.22+ 对
math.IsNaN做了内联优化，但旧版本仍建议避免高频调用点嵌套过深 - 如果判定逻辑复杂（比如要同时检查 NaN + 范围 + 符号），优先合并条件，而不是拆成多个
math.IsXxx调用
Inf 和 NaN 的本质是浮点数的特殊状态，不是错误值；很多 bug 出在把它们当成“异常”去 recover，而不是作为合法输入来设计分支逻辑。真正难的不是怎么判断，是怎么让整个数据流（输入解析 → 计算 → 存储 → 输出）对它们有一致的语义约定。
