防整数溢出必须运算前检查，std::add_overflow比手写if更可靠，因其不执行实际加法、语义明确、支持全类型且基于编译器内建指令；旧版可用__builtin_add_overflow；必要时应换用int64_t等更大类型而非硬加检查。
直接说结论：防整数溢出不能靠“事后补救”，必须在运算发生前做检查、用对工具、选对类型——否则未定义行为（UB）已经触发，结果不可信，连判断都失效。
std::add_overflow 为什么比手写 if 更可靠
很多人写 a > INT_MAX - b 检查加法溢出，但这个表达式本身就有风险：INT_MAX - b 在 b 为负时可能再次溢出；而且它只覆盖正数场景，a 和 b 一正一负时逻辑更复杂。
-
std::add_overflow(a, b, &result)是 C++23 标准函数，语义明确：不执行实际加法，只做安全判定并写入结果（成功时返回true） - 它内部使用编译器内建指令（如
__builtin_add_overflow），生成的汇编高效且不依赖平台算术细节 - 支持所有算术类型组合（
int、long long、unsigned等），无需手动区分符号 - 注意：GCC 13+、Clang 16+、MSVC 17.8+ 才完整支持；旧版本项目请直接用
__builtin_add_overflow
什么时候该换类型，而不是硬加检查
不是所有溢出都要靠运行时检查兜底。有些场景，换类型是更干净、更少出错的选择。
- 计算时间戳、文件偏移、内存地址——直接用
int64_t或std::ptrdiff_t，避免int在 32 位环境或大系统中翻车 - 容器索引和 size 相关运算——别用
int存vec.size()，改用size_t或decltype(vec.size())，但要注意和负数比较时的隐式转换陷阱 - 常量计算（比如
2 * 1024 * 1024 * 1024）——加LL后缀，如1LL * 2 * 1024 * 1024 * 1024，强制全程用long long算，防止中间int溢出 - 别盲目升级到
size_t：它无符号，vec.size() - 1在空容器时会绕成极大值，反而更危险
std::midpoint 不是万能平均函数，但二分查找里必须用
std::midpoint(low, high) 的核心价值不在“求平均”，而在安全算索引——它绕开了 (low + high) / 2 的中间加法溢出问题。
- 仅接受同类型算术参数：
std::midpoint(int, int)合法，std::midpoint(int, long)编译失败，必须显式static_cast - 指针版本
std::midpoint(p, q)要求p和q指向同一数组，否则未定义行为 - 它不保证数学上“居中”：当
a = INT_MIN、b = INT_MAX时结果确定，但可能不符合直觉；不过二分查找中low ≤ high恒成立，完全适用 - 别把它当通用替代品去算浮点平均——
std::midpoint(float, float)编译报错，C++20 标准未提供浮点特化
编译器 sanitizer 和静态分析只是辅助，不能替代代码逻辑
-fsanitize=signed-integer-overflow 在测试时能快速暴露问题，但它不是生产环境的解决方案。
- UBSan 会让程序在溢出时 abort 并打印堆栈，但性能开销 2–5 倍，且不覆盖所有路径（比如某些位运算、指针算术）
- 它不检测无符号溢出（C++ 标准规定这是回绕，非 UB），而业务上往往需要感知这种回绕
-
-fanalyzer（GCC）或 Clang Static Analyzer 可以发现部分明显模式，但覆盖率有限，不能代替人工检查关键路径 - 真正要命的是那些“看起来正常”的 UB：优化开启后，编译器可能直接删掉
if (a + b 这类判断——因为它假设有符号溢出不会发生
最易被忽略的点：所有用户输入、外部数据、循环计数器、容器迭代器差值，只要参与算术，就得统一考虑溢出路径。不是写一次检查就完事，而是让每处数值操作都有明确的边界契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
