因为32位有符号整数采用二进制补码表示，最高位为符号位；当加法结果超出上限2147483647时，符号位翻转为1，硬件按模2³²运算后被解释为负数（如2147483647+1得-2147483648），NumPy默认静默回绕而不报错。
为什么 np.int32 加法会突然变负数？
因为整数溢出后发生回绕（wraparound），不是报错而是静默出错。比如两个接近 2**31-1 的 np.int32 相加，结果直接跳到负数区间——NumPy 默认不检查溢出，底层用 C 的行为。
- 典型现象：
np.array([2147483647], dtype=np.int32) + np.array([1], dtype=np.int32)返回[-2147483648] - 只在整数类型（
np.int8/np.int16/np.int32/np.int64）上发生；浮点类型（np.float32/np.float64）溢出会转为inf或nan，至少有迹可循 - 触发场景常见于图像像素运算（
uint8累加）、索引计算、计数器累加等
怎么让 NumPy 在溢出时报警而不是硬算？
用 np.seterr(over='raise') 对浮点溢出有效，但对整数溢出无效——这是 NumPy 的设计限制。真正可行的方案是提前升阶 dtype 或启用运行时检测。
- 最稳妥：统一用更高位宽整数，如把
np.int32改成np.int64，或np.uint8改成np.uint16，尤其在累加、求和前显式转换：arr.astype(np.int64).sum() - 临时检测：用
np.errstate(over='raise')包裹浮点运算，但别指望它拦住int32 + int32 - 调试阶段可加断言：
assert np.all(arr ，适用于已知范围的输入
np.clip() 和 np.where() 能替代溢出处理吗？
不能“修复”溢出，但能防止后续逻辑崩坏。它们是在溢出发生后做截断或替换，属于补救而非预防。
-
np.clip(arr, 0, 255)对uint8图像有用，但若中间计算已溢出（比如先算出 -100），再 clip 就丢了原始意图 -
np.where(arr > 255, 255, arr)同理，只管输出值，不管中间是否翻车 - 适合场景：明确接受饱和语义（如音量最大值限制、RGB 截断），不适合需要精确累加的统计或索引计算
哪些函数自带 dtype 安全机制？
少数聚合函数支持 dtype 参数指定计算精度，但多数二元运算（+, *, np.add）完全继承输入 dtype。
立即学习“Python免费学习笔记（深入）”；
-
np.sum(arr, dtype=np.int64)—— 关键！即使arr是int32，也能在内部用int64累加 -
np.cumsum(arr, dtype=np.float64)同理，适合避免累积误差+溢出 -
np.add等 ufunc 没有dtype参数，必须靠输入数组 dtype 控制，所以推荐先astype再调用
最容易被忽略的是：NumPy 的广播规则会让小 dtype “污染”大 dtype，比如 int32 数组和 int64 标量相加，结果仍是 int32。得手动强制升阶，不能依赖自动推导。
