C++23起可用std::add_overflow安全检测整数加法溢出，需包含<utility>，要求操作数与结果类型相同，返回bool表示是否溢出，并通过输出参数写入结果；C++11至C++17不支持，须用__builtin_add_overflow或手动前置边界检查。
用 std::add_overflow 判断加法是否溢出（C++23）
如果你用的是支持 C++23 的编译器（如 GCC 13+、Clang 17+），std::add_overflow 是最直接、最安全的选择。它不依赖符号位假设，也不触发未定义行为，返回 bool 表示是否溢出，并通过输出参数写入结果值。
常见错误是直接写 a + b > INT_MAX —— 这在 a + b 实际溢出时已是未定义行为，编译器可能优化掉判断逻辑，导致误判。
-
std::add_overflow要求两个操作数和结果类型一致（如都是int），不能混用int和long long - 它只处理加、减、乘三种运算，不支持除法或取模
- 对无符号类型也有效，但无符号溢出本身是定义良好的（回绕），所以通常只用于有符号类型校验
#include <utility>
int a = INT_MAX, b = 1;
int result;
if (std::add_overflow(a, b, &result)) {
// 溢出发生
}
手动检查加法前的边界（C++11 及以上通用）
在没有 C++23 支持时，必须在执行加法前判断：若 a > 0 且 b > INT_MAX - a，则 a + b 必溢出；类似处理负数情况。关键点在于所有运算都落在安全范围内，不真正执行可能导致 UB 的加法。
容易踩的坑是只检查一种符号组合，比如忽略 a < 0 && b < 0 导致下溢（即小于 INT_MIN）。
立即学习“C++免费学习笔记（深入）”；
- 对
int类型，需同时检查上溢（>INT_MAX）和下溢（<INT_MIN） - 用
static_cast<long long>扩展中间计算可避免部分误判，但要注意目标类型仍是int，不能靠long long存结果来“绕过”溢出 - 宏或模板封装这类检查逻辑更可靠，避免每次手写条件出错
bool would_add_overflow(int a, int b) {
if (b > 0 && a > INT_MAX - b) return true;
if (b < 0 && a < INT_MIN - b) return true;
return false;
}
为什么不能依赖 std::numeric_limits<T>::is_modulo 或异常
std::numeric_limits<int>::is_modulo 返回 true，但这只说明该类型数学上是模运算，**不表示溢出会被捕获或抛异常**——C++ 有符号整数溢出就是未定义行为，不会自动抛 std::overflow_error，也不会设置标志位。
有人试图用 volatile 强制不优化、再检查结果值，但这是不可靠的：UB 一旦发生，整个程序状态无效，后续任何检查都无意义。
- 信号（如
SIGFPE）在某些平台可能被触发，但不是标准行为，不可移植 - 编译器（如 GCC）的
-ftrapv选项会插入运行时检查，但它让溢出转为abort()，无法用于可控恢复逻辑 - 不要尝试用
try/catch捕获整数溢出——它根本不会抛异常
乘法和减法的溢出检查要单独处理
加法检查不能直接套用到乘法：例如 INT_MAX / a < b 在 a == 0 时除零，a 为负时不等号方向翻转，还要考虑 INT_MIN 的不对称性（abs(INT_MIN) > abs(INT_MAX)）。
减法可统一转为加法检查：a - b 等价于 a + (-b)，但注意 -INT_MIN 本身就会溢出（因为 INT_MIN 没有对应正数），所以必须先判断 b == INT_MIN 再决定是否取负。
- 乘法检查建议用
long long中间存储并比较范围，但前提是确保long long至少比int宽（通常成立） - 使用
std::mul_overflow（C++23）或std::sub_overflow更省心，语义清晰且无平台差异 - 如果项目锁定了旧标准，推荐用已验证的工具库函数，比如 LLVM 的
__builtin_add_overflow（GCC/Clang 支持），而非自己推导全部边界
实际写业务逻辑时，最容易被忽略的是：溢出检查必须覆盖所有路径，包括负数参与的每种组合，且不能把“没崩溃”当成“没溢出”。未定义行为可能在不同优化等级下表现不同，调试时看似正常，上线后突然出错。
