short int 溢出后值怎么变？不是随机的
有符号 short int 溢出是未定义行为（UB），但绝大多数主流编译器（GCC、Clang、MSVC）在默认设置下实际走的是**二进制补码截断**——也就是只保留低 16 位，再按补码规则解释。这不是标准保证的，但它是你调试时“看到”的真实结果。
比如 short x = 32767;（即 0x7FFF），再执行 x++，结果通常是 -32768（即 0x8000）。这不是“归零”，而是最高位变成符号位后，数值自然翻转。
- 溢出方向决定翻转点：
32767 + 1 → -32768，-32768 - 1 → 32767 - 本质是模 2¹⁶ 运算后重新符号扩展：结果 ≡ 原值 (mod 65536)，再以 16 位有符号整数解读
- 别依赖它做循环计数——一旦开启优化（如
-O2），编译器可能直接删掉整个溢出分支，因为 UB 允许它假设溢出永不发生
为什么用 short 却意外得到 int 类型运算？
因为 C++ 的**整型提升（integer promotion）**：几乎所有算术运算前，short 会先隐式转成 int。这意味着 short a = 32767, b = 1; auto c = a + b; 中，c 的类型是 int，溢出发生在 int 层面（几乎不会），而非 short 层面。
- 只有赋值或显式强制转换回
short时，才可能触发截断：如short c = a + b; - 函数传参、模板推导、
auto都受提升影响，别以为写short就全程按 16 位算 - 数组索引、
for循环变量用short？小心中间表达式早就是int了，溢出检测完全失效
如何安全检测 short 溢出？别用 if(x > 32767)
直接比较边界值看似简单，但编译器可能优化掉（尤其开启 -O2 后，它知道 x > 32767 对 short 永假）。更可靠的是在运算前检查，或用无符号类型辅助判断。
立即学习“C++免费学习笔记（深入）”；
- 加法前检查：
if (x > 0 && y > 0 && x > SHRT_MAX - y) /* 溢出 */ - 减法前检查：
if (x 0 && x - 用
unsigned short算，再判断符号位是否异常翻转（适合嵌入式等确定性场景） - 现代方案：用
std::add_overflow（C++23）或__builtin_add_overflow（GCC/Clang）——它们生成带进位标志的汇编，不依赖 UB 假设
char、short、int 在循环里混用的坑
写 for (short i = 0; i ，其中 <code>len 是 size_t 或 int，问题立刻出现：比较时 i 被提升为 int，但若 len > 32767，循环可能提前终止或死循环（取决于符号扩展行为）。
-
short和size_t比较？必然先转成size_t，但负的short会变成巨大正数（如(size_t)(-1)是 18446744073709551615） - 容器遍历别用
short当索引——std::vector::size()返回size_t，隐式转换风险极高 - 跨平台时更危险：Windows 上
int是 32 位，但某些嵌入式平台int只有 16 位，此时short提升行为可能不同
真正麻烦的不是溢出结果本身，而是它让代码在调试时“看起来正常”，一开优化就行为突变；还有那些隐式提升和类型混合，比越界本身更难定位。
