有符号整数溢出是未定义行为，编译器可任意优化或破坏程序逻辑，不保证截断或模运算，且会危及下游内存访问；应启用UBSan、编译警告，改用无符号类型或带检查的运算。
有符号整数溢出是未定义行为，不是“结果错一点”，而是整个程序逻辑可能崩塌
为什么int加法溢出后不能靠“截断”来预测结果
C++标准明确规定：有符号整数溢出属于undefined behavior（UB），编译器可以任意处理——包括优化掉整条语句、生成随机值、甚至删掉后续代码。它不保证模运算，也不保证变成最小值。
- 例如
int x = INT_MAX; x++;后，x的值完全不可观测，if (x 可能被编译器直接优化为 <code>false，即使你“以为”它该绕回负数 - Clang/GCC 在
-O2下常利用 UB 做激进优化：把依赖溢出结果的分支整个剪掉 - 调试时看到“似乎绕回了”，只是当前编译器/平台/优化等级下的偶然现象，换一个环境就失效
std::vector::size() 或循环计数器用 int 时的典型崩溃链
很多开发者习惯写 for (int i = 0; i ，但 <code>v.size() 返回的是 size_t（无符号）。当 v.size() > INT_MAX 时，隐式转换触发溢出 UB；更隐蔽的是，若循环中 i 被误算超限（如 i += step），后续用它做数组索引会直接越界。
- 风险点不止在计算本身，还在它下游的内存访问：
arr[i]中的i若是 UB 衍生值，ASan 可能报heap-buffer-overflow，但根源在前面的加法 - 嵌入式或 32 位系统上，
INT_MAX仅约 21 亿，大缓存/图像处理场景极易触达 - 用
size_t替代int做索引虽可避免有符号溢出，但需同步检查是否真需要有符号语义（比如要支持负偏移）
如何检测和规避——别只靠 -fsanitize=undefined
AddressSanitizer 能捕获运行时溢出，但 -fsanitize=undefined（UBSan）才是专治有符号溢出的工具。不过它只在运行时生效，且对性能影响明显；静态手段更前置。
立即学习“C++免费学习笔记（深入）”；
- 启用编译警告：
-Wsigned-integer-overflow（Clang）或-Woverflow（GCC），但默认不开启，需显式加 - 用
std::add_overflow（C++26）或第三方库如absl::int128/boost::safe_numerics做带检查的运算 - 关键路径（如协议解析、内存分配大小计算）强制用
uint64_t+ 显式范围校验，避开有符号类型
最易被忽略的是：溢出不一定发生在“大数相加”那一刻，而常藏在指针差值、容器迭代器距离、时间戳差分等看似安全的表达式里——只要涉及有符号类型和潜在大跨度，就得按 UB 对待。
