应主动预防int溢出，因有符号整数溢出是未定义行为；可通过std::numeric_limits检查边界、__builtin_add_overflow安全计算、升级至C++23用std::add_overflow，或改用int64_t等更稳健类型。
怎么判断 int 真的溢出了？
C++ 标准里，有符号整数（如 int）溢出是未定义行为（UB），不是抛异常、也不是返回错误码——它可能算出错值、崩溃、甚至看起来“正常”但结果随机。所以不能靠“等它出错再处理”，得主动防。
- 用
std::numeric_limits<int>::max()</int> 和 std::numeric_limits<int>::min()</int> 查当前平台的上下界（注意：int 不一定是 32 位，嵌入式或旧编译器可能更小）
- 加法前先检查：
a > INT_MAX - b 判断 a + b 是否溢出（适用于正数相加）；减法类似，但要分正负组合，逻辑变多
- 更稳妥的做法：改用
long long 临时计算，再判断是否在 int 范围内——但别滥用，它不解决根本问题，只是延后风险
用 std::add_overflow 还是自己写检查？
C++23 引入了 std::add_overflow、std::mul_overflow 等函数，能安全做带溢出检测的算术。但现实是：
- GCC 13+、Clang 16+ 才开始支持，MSVC 2022 17.8+ 也支持，但很多项目还卡在 C++17 或 C++20
- 如果不能升标准，就别依赖它；硬上会编译失败，且无法 fallback
- 自己写检查容易漏边界（比如
INT_MIN - (-1) 就是溢出），建议直接抄 LLVM 的 __builtin_add_overflow（GCC/Clang 支持）：bool overflow = __builtin_add_overflow(a, b, &result);
它生成的汇编高效，且语义明确——比手写 if 判断更可靠
什么时候该换类型，而不是死磕 int？
不是所有场景都适合“加检查”。如果业务逻辑天然涉及大数（比如时间戳毫秒累加、内存地址偏移、计数器超亿级），继续用 int 就是给自己埋雷。
- 优先考虑
int64_t：跨平台、大小确定、现代 CPU 处理效率不输 int
- 避免盲目用
size_t：它是无符号、和指针同宽，但和负数运算混用极易引发隐式转换 bug（比如 vec.size() - 10 在空容器时变成极大正数）
- 容器索引别用
int：STL 的 size() 返回 size_t，和 int 比较会触发 signed/unsigned 警告，且可能截断——老老实实用 auto i = vec.size() 或 size_t i
Release 模式下溢出更危险？
Debug 模式下某些编译器（如 MSVC 的 /RTC）会插桩检测溢出，但 Release 下全关——UB 就真 UB 了。
-
-fsanitize=signed-integer-overflow（Clang/GCC）能在测试时暴露问题，但不能进生产（性能损耗大、且只报错不停止）
- 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 能扫出部分潜在溢出点，但覆盖率有限
- 最实际的防线：关键计算路径（比如协议解析、资源配额、循环终止条件）必须显式检查，哪怕多几行代码——这里省事，线上 core dump 就得通宵查
std::numeric_limits<int>::max()</int> 和 std::numeric_limits<int>::min()</int> 查当前平台的上下界（注意：int 不一定是 32 位，嵌入式或旧编译器可能更小）a > INT_MAX - b 判断 a + b 是否溢出（适用于正数相加）；减法类似，但要分正负组合，逻辑变多long long 临时计算，再判断是否在 int 范围内——但别滥用，它不解决根本问题，只是延后风险std::add_overflow 还是自己写检查？
C++23 引入了 std::add_overflow、std::mul_overflow 等函数，能安全做带溢出检测的算术。但现实是：
- GCC 13+、Clang 16+ 才开始支持，MSVC 2022 17.8+ 也支持，但很多项目还卡在 C++17 或 C++20
- 如果不能升标准，就别依赖它；硬上会编译失败，且无法 fallback
- 自己写检查容易漏边界（比如
INT_MIN - (-1)就是溢出），建议直接抄 LLVM 的__builtin_add_overflow（GCC/Clang 支持）：bool overflow = __builtin_add_overflow(a, b, &result);
它生成的汇编高效，且语义明确——比手写 if 判断更可靠
什么时候该换类型，而不是死磕 int？
不是所有场景都适合“加检查”。如果业务逻辑天然涉及大数（比如时间戳毫秒累加、内存地址偏移、计数器超亿级），继续用 int 就是给自己埋雷。
- 优先考虑
int64_t：跨平台、大小确定、现代 CPU 处理效率不输 int
- 避免盲目用
size_t：它是无符号、和指针同宽，但和负数运算混用极易引发隐式转换 bug（比如 vec.size() - 10 在空容器时变成极大正数）
- 容器索引别用
int：STL 的 size() 返回 size_t，和 int 比较会触发 signed/unsigned 警告，且可能截断——老老实实用 auto i = vec.size() 或 size_t i
Release 模式下溢出更危险？
Debug 模式下某些编译器（如 MSVC 的 /RTC）会插桩检测溢出，但 Release 下全关——UB 就真 UB 了。
-
-fsanitize=signed-integer-overflow（Clang/GCC）能在测试时暴露问题，但不能进生产（性能损耗大、且只报错不停止）
- 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 能扫出部分潜在溢出点，但覆盖率有限
- 最实际的防线：关键计算路径（比如协议解析、资源配额、循环终止条件）必须显式检查，哪怕多几行代码——这里省事，线上 core dump 就得通宵查
int64_t：跨平台、大小确定、现代 CPU 处理效率不输 int
size_t：它是无符号、和指针同宽，但和负数运算混用极易引发隐式转换 bug（比如 vec.size() - 10 在空容器时变成极大正数）int：STL 的 size() 返回 size_t，和 int 比较会触发 signed/unsigned 警告，且可能截断——老老实实用 auto i = vec.size() 或 size_t i
-
-fsanitize=signed-integer-overflow（Clang/GCC）能在测试时暴露问题，但不能进生产（性能损耗大、且只报错不停止） - 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 能扫出部分潜在溢出点，但覆盖率有限
- 最实际的防线：关键计算路径（比如协议解析、资源配额、循环终止条件）必须显式检查，哪怕多几行代码——这里省事，线上 core dump 就得通宵查
溢出问题从来不在“会不会发生”，而在“发生时你能不能立刻定位到哪一行、哪个变量、哪个分支”。靠运气拦截 UB，不如从第一行计算就带上边界意识。
