short加法溢出按模65536运算并解释为有符号数，如32767+1得-32768；因整型提升，short+short实际为int运算，结果非short；static_cast不能避免溢出，仅延后截断；仅内存敏感场景宜用short。
short int 加法溢出后值怎么变
溢出不是随机的，是按模运算：两个 short 相加，结果对 65536 取模（有符号则对 65536 取模后再解释为有符号16位整数）。比如 32767 + 1 不是报错，而是变成 -32768。
这是因为 C++ 标准规定：有符号整数溢出是未定义行为（UB），但几乎所有主流编译器（GCC、Clang、MSVC）在默认设置下实际按二进制补码模运算处理——你不能依赖它，但得知道它通常怎么“跑”。
- 实际开发中，
short加法不检查溢出，编译器几乎从不插入运行时检查 - 启用
-fsanitize=undefined（Clang/GCC）可捕获这类 UB，但会明显拖慢程序 - 如果真要安全计算，别用裸
short加法，改用std::add_overflow（C++23）或手动判断边界
为什么 short + short 不等于 short
因为 C++ 的整型提升规则：只要操作数能放进 int，就会先转成 int 再算。所以 short a = 1, b = 2; auto c = a + b; 中，c 类型是 int，不是 short。
这意味着你写 a + b 看似是两个 short 运算，实际是两次提升 + 一次 int 加法 + 可能的隐式截断（如果你赋给 short 变量）。
立即学习“C++免费学习笔记（深入）”；
- 赋值回
short才真正触发截断：如short d = a + b;—— 此时才可能静默丢失高位 - 函数传参时也受提升影响：
void f(short); f(a + b);会先算int结果，再隐式转short，溢出在此刻发生 - 模板推导（如
auto x = a + b;）永远推成int，不是short
用 static_cast 强制 short 加法靠谱吗
不靠谱。写 static_cast<short>(a + b)</short> 并没绕过溢出问题，只是把已发生的 int 结果强行截断，且仍属未定义行为（如果原 int 值超出 short 表示范围）。
更危险的是：它掩盖了类型提升事实，让你误以为“控制了运算过程”，其实只是延后了截断点。
- 想确保 16 位运算语义？用
int16_t+ 显式检查，或启用编译器溢出检测 -
static_cast无法阻止提升，也不能让加法在short范围内做——硬件没有这种指令，C++ 也没有这种语义 - 某些嵌入式场景用
__builtin_add_overflow更直接，但非标准，移植性差
哪些场景真该用 short
只在明确需要节省内存且数据范围严格受限时用，比如：大量数组存传感器采样值（-32768 ~ 32767）、网络协议字段、文件二进制布局对齐要求。
日常计算、中间变量、函数返回值、容器元素（除非 vector<int16_t></int16_t> 明确优化空间）——一律用 int 或 int32_t 更安全、更高效。
- x86-64 上，
short运算常被扩展成 32 位指令执行，反而没int快 - 结构体里混用
short和int可能因对齐导致填充字节增多，未必省空间 - 调试器显示、日志打印、JSON 序列化等环节，
short常被自动转成int，容易让人忽略它本意
补码溢出、整型提升、隐式截断——这三者叠在一起，才是 short 最容易出问题的地方。它们不报错，也不警告，默认就静默发生。
