有符号整数溢出是未定义行为，不可依赖“int_max + 1 = int_min”；应优先用边界预判、升级类型（如int64_t）、编译器内置函数（如__builtin_add_overflow）和undefinedbehaviorsanitizer检测。
这其实不是“变成负数”，而是有符号整数溢出触发了未定义行为——编译器可以优化掉代码、让程序崩溃，或者输出看似合理但完全不可靠的结果。所谓“INT_MAX + 1 = INT_MIN”只是某些平台、某些编译选项下偶然出现的现象，不能当作规律依赖。
别在运行时猜结果，改用预判式边界检查
事后检查 x + 1 或 <code>x == INT_MAX 都不安全：前者对负数失效，后者无法覆盖所有溢出路径（比如乘法、减法）。正确做法是在运算前判断：
- 加法前检查：
a > std::numeric_limits<int>::max() - b</int>→ 上溢风险 - 减法前转为加法处理：
a - b等价于a + (-b)，复用同一套预判逻辑 - 乘法要额外小心：
abs(b) > std::numeric_limits<int>::max() / abs(a)</int>，但需先排除a == 0和a == INT_MIN（因为-INT_MIN本身就会溢出）
优先升级类型，而不是硬加防御逻辑
如果业务天然涉及大数（如累计计数、时间差、ID 运算），反复做溢出检查反而增加错误概率和维护成本。更干净的解法是直接换类型：
- 用
long long或int64_t替代int：保证至少 64 位，范围足够覆盖绝大多数场景 - 避免隐式降级：比如
int a = 2e9; long long b = a * 2;是错的——乘法仍按int算，早已溢出；应写成long long a = 2e9; auto b = a * 2LL;
用编译器内置函数做运行时兜底
预判虽好，但复杂表达式（如多步混合运算）容易漏判。GCC/Clang 提供高效可靠的内置函数：
-
__builtin_add_overflow(a, b, &result)：不执行真实加法，只判断是否溢出，并把安全结果写入result - 配套还有
__builtin_sub_overflow、__builtin_mul_overflow - 注意：MSVC 不支持，跨平台项目需
#ifdef __GNUC__或迁移到 C++23 的std::add_overflow
开发阶段必须开 UndefinedBehaviorSanitizer
加编译选项 -fsanitize=undefined，它能在运行时捕获 signed integer overflow 并精准报错。这不是可选建议，而是底线配置——很多溢出问题在测试环境“看起来正常”，一上生产就因优化级别变化而暴露逻辑跳变或崩溃。
