np.float64溢出因表示范围上限（≈1.8e308）而非精度不足，常见于exp等运算；判断相等应优先用np.allclose而非==。
为什么 np.float64 计算还会触发 RuntimeWarning: overflow encountered in double_scalars
这不是精度“不够”，而是浮点数的表示范围有硬上限（np.finfo(np.float64).max ≈ 1.8e308）。一旦中间结果超过它，就直接溢出为 inf，NumPy 默认会警告。常见于指数运算（如 np.exp(x)）、大数阶乘近似、或未归一化的 softmax 分母。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
np.errstate(over='ignore')临时屏蔽警告（仅限你确认溢出可接受，比如后续会做np.nan_to_num处理） - 更安全的做法是提前截断：对
np.exp(x)，先做x = np.clip(x, -700, 700)（因为exp(700) ≈ 1e304，留余量） - 若用于 softmax，直接改用
scipy.special.softmax或手动减去最大值：x = x - x.max(axis=-1, keepdims=True)
如何判断两个 np.float64 是否“数学上相等”而非逐位相等
直接用 == 比较浮点数几乎总是错的——哪怕只是 0.1 + 0.2 != 0.3。NumPy 提供了专用于此的函数，但选错参数会埋坑。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先用
np.allclose(a, b, rtol=1e-05, atol=1e-08)：它同时检查相对误差和绝对误差，适合大多数场景 - 避免只设
atol（比如atol=1e-10）却忽略rtol——当a和b是1e20级大数时，1e-10绝对误差毫无意义 - 若需逐元素布尔结果，用
np.isclose(a, b)，别手写abs(a-b) - 注意
np.array_equal()对浮点数不鲁棒，它内部用的是严格相等
为什么 np.sum(arr, dtype=np.float32) 反而比默认 float64 更容易溢出
默认情况下，np.sum 会将输入提升到平台原生浮点类型（通常是 float64），而显式指定 dtype=np.float32 强制使用单精度，其上限只有 ~3.4e38，且累积过程不自动升精度。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 除非内存极度受限且你确认数值范围安全，否则不要主动降
dtype；默认行为通常更稳健 - 若必须用
float32输入，改用np.sum(arr, dtype=np.float64)显式指定高精度累加器 - 对超大数组，考虑分块累加：
np.sum(arr.reshape(-1, 10000), axis=1).sum()，减少单次累积长度
np.seterr 全局设置 vs np.errstate 上下文管理哪个该用
全局设置影响整个进程所有 NumPy 调用，极易引发隐蔽副作用；上下文管理只作用于代码块内，是推荐做法。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 永远优先用
with np.errstate(divide='ignore', invalid='warn'):包裹可疑计算段 - 避免在模块顶层调用
np.seterr(all='raise')——它会让第三方库（如 scikit-learn 内部的除零）直接崩掉 - 若真要全局压制（如训练循环中频繁出现无害的
log(0)），至少限定范围：np.seterr(divide='ignore', invalid='ignore')，别用all - 记住
np.errstate不继承：函数内新开的with块不会受外层影响
最常被忽略的一点：警告不是错误，但默认开启的 RuntimeWarning 容易掩盖真正的问题。与其反复调 seterr，不如顺着警告信息定位到具体哪行计算、什么输入导致了溢出或无效值——那才是根因。
