short 自增时为什么突然变成负数
因为 short 是有符号类型，通常占 2 字节，取值范围是 -32768 到 32767。一旦自增越过上限，就会发生有符号整数溢出，结果未定义（C++11 起）或回绕（依赖编译器实现，但多数按补码回绕为 -32768）。
常见错误现象：short x = 32767; ++x; 后 x 变成 -32768，而不是报错或卡住。
- 别指望编译器自动拦截——
++对short是合法操作，不会触发警告（除非开启-Woverflow或-fsanitize=undefined） - 如果逻辑上需要计数且可能超 32767，直接用
int；short适合存数据，不适合做频繁算术的变量 - 在嵌入式或内存敏感场景才考虑用
short做循环变量，但务必确认迭代次数绝对不越界
short 运算时悄悄提升成 int
C++ 的“整型提升”规则会让所有小于 int 的整型（包括 short）在参与运算前先转成 int。这意味着 short + short 实际是 int + int，结果也是 int。
使用场景：当你写 short a = 1000, b = 2000; short c = a + b;，编译器会先算 int(1000) + int(2000) 得到 3000，再隐式截断赋给 c——这步截断不报错，但若和超出 short 范围，就丢数据。
立即学习“C++免费学习笔记（深入）”；
- 赋值前检查：用
if (a + b > std::numeric_limits<short>::max())</short>判断是否溢出（注意：这里a + b已是int，安全） - 避免隐式截断：显式用
static_cast<short>(a + b)</short>，但得自己确保不越界 - 禁用整型提升？不行——这是语言标准行为，无法关闭
自增运算符 ++ 对 short 的实际行为
++x 和 x++ 对 short 变量是安全的语法，但语义上仍是“先提升、再计算、再截断回 short”。关键点在于：这个“截断”发生在写回变量前，不经过任何溢出检查。
容易踩的坑：for (short i = 0; i 看似正常，但 <code>i 到 32767 后下一次自增就变 -32768，条件 i 仍为真，循环永远停不下来（死循环）。
- 永远不要用
short做循环控制变量，除非你 100% 确认上限远低于 32767 - 用
-fsanitize=undefined编译可捕获运行时有符号溢出（报signed integer overflow），但仅限调试阶段 -
++和+= 1行为一致，别以为后者更“安全”
什么时候真的该用 short
只在两个明确场景下用 short：一是与外部二进制协议/文件格式对齐（比如某传感器固件规定温度字段占 2 字节有符号整）；二是大规模数组且内存占用成为瓶颈（如百万级 short 数组 vs int，省 2MB）。
其他情况，尤其是涉及算术、比较、循环、函数参数传递，优先选 int——它在现代 CPU 上通常更快，且无隐式截断风险。
- 函数传参：别写
void f(short x)，除非接口契约强制要求；传int更通用 - 容器存储：用
std::vector<short></short>没问题，但访问后参与运算前，心里要有“它马上要升成 int”的意识 - 跨平台注意：
short至少 16 位，但某些嵌入式平台可能恰好就是 16 位，而桌面平台虽也是 16 位，但溢出行为未必一致——别依赖具体回绕值
最常被忽略的一点：溢出不是“偶尔出错”，而是“只要输入组合满足条件就必现”，而且往往在边缘数据（比如第 32768 次请求）上爆发，压测容易漏掉。
