整型溢出是未定义行为，可能导致截断、崩溃或优化错误；有符号溢出尤其危险，编译器可任意假设其不发生；需通过类型选择、边界检查、 sanitizer 和静态分析主动防御。
整型溢出本质是运算结果超出了目标类型的可表示范围，C++标准规定这是未定义行为（UB），编译器可任意处理——可能截断、崩溃、优化掉关键逻辑，甚至产生看似正常却错误的结果。
有符号整型：溢出即未定义行为
对 int 等有符号类型，加减乘等运算若结果超出 [INT_MIN, INT_MAX]，行为完全不可预测。例如：
-
int x = INT_MAX; x++; —— 不保证变成 INT_MIN，也不保证报错，编译器可能直接删掉这行（因假设它不会发生）
- 循环条件 for (int i = 0; i 中，若 n == INT_MAX，i++ 后溢出，整个循环可能被优化为死循环或空操作
无符号整型：自动回绕，但易被误用
无符号类型（如 unsigned int）溢出是明确定义的：模 2^N 回绕。例如 UINT_MAX + 1 == 0。问题在于：
- 混用有/无符号运算时隐式转换：int a = -1; unsigned b = 1; if (a → a 被转为大正数，条件恒真
- 容器索引误用：vector::size() 返回 size_t（无符号），写 for (int i = v.size()-1; i >= 0; --i) 会导致 i 变成极大正数后循环失控
常见高危场景与规避建议
以下操作极易触发溢出且难以察觉：
-
数组下标计算：避免 ptr[i * stride + offset] 中 i * stride 溢出；先检查乘法是否安全，或改用 size_t 并配合 std::numeric_limits
-
时间差计算：int start = clock(); ... int diff = clock() - start; —— 若间隔长，clock() 返回值可能绕回，应使用 long long 或 std::chrono
-
内存分配大小：如 malloc(n * sizeof(T))，当 n 很大时乘法溢出导致分配过小内存，后续写入越界；应先用 if (n > SIZE_MAX / sizeof(T)) 检查
实用防御手段
不依赖运行时检测，而从设计和编码习惯入手：
- 优先使用足够宽的类型：如计数器用 size_t，大范围数值用 long long
- 启用编译器溢出检查：Clang/GCC 加 -fsanitize=undefined，可捕获多数运行时溢出
- 用安全算术库辅助：如 absl::checked_add 或 C++23 的 std::add_overflow
- 静态分析工具介入：Cppcheck、PVS-Studi
o 能识别潜在溢出模式
基本上就这些。溢出不是“偶尔出错”，而是代码逻辑里埋着的定时炸弹——不炸则已，一炸就难定位。关键是把范围意识融入每一步计算，而不是等崩溃了再查。
o 能识别潜在溢出模式