short溢出不报错因属未定义行为，运行时截断高位致结果错误；其大小非固定2字节，跨平台应优先用int16_t；函数传参会自动提升为int，隐式转换易引发逻辑错误。
short 类型溢出时为什么没报错，但结果错了
因为 short 是有符号整型，默认范围是 -32768 到 32767（16 位），超出后发生**未定义行为（UB）**，编译器通常不拦截，运行时直接截断高位——比如 32767 + 1 可能变成 -32768，而不是抛异常或警告。
- 常见错误现象：
short x = 32767; ++x;后x变成-32768，但代码照常执行，调试时才发现逻辑崩了 - 使用场景：嵌入式或内存敏感环境才真用
short；普通业务逻辑里，多数时候只是“省了 2 字节”，却换来隐性风险 - 编译器差异：GCC/Clang 加
-fsanitize=undefined能捕获运行时溢出；MSVC 需启用/RTCc（仅 Debug 模式） - 性能影响：无实际提升——现代 CPU 对
int和short的算术指令吞吐基本一致，反而可能因对齐补零增加访存开销
sizeof(short) 不一定是 2，别硬编码
short 只保证至少 16 位（C++ 标准），但具体字节数由平台 ABI 决定。虽然绝大多数桌面系统是 2 字节，但某些 DSP 或老嵌入式平台可能是 4 字节，甚至 1 字节（极少见）。
- 常见错误现象：用
char buf[sizeof(short)]做序列化，换平台后读写出错 - 正确做法：永远用
sizeof(short)，别写死2；跨平台序列化优先用int16_t（来自<cstdint></cstdint>） - 参数差异：
short无固定大小，int16_t明确是 16 位有符号整数，且不存在则编译失败（可用static_assert检查）
函数传参时 short 自动提升为 int，小心隐式转换
C++ 整型提升规则会让所有小于 int 的整型（包括 short）在作为函数实参、算术表达式操作数时，先转成 int。这意味着你写的 void f(short x)，调用 f(5) 实际上传的是 int，再被截断——容易漏掉警告。
- 常见错误现象：重载函数
void f(short)和void f(int)，传字面量5会调f(int)，不是预期的short版本 - 调试技巧：在函数入口加
static_assert(sizeof(x) == sizeof(short), "x not short?");，可暴露是否被提升 - 兼容性影响：开启
-Wconversion（GCC/Clang）能警告从int到short的隐式截断，但默认关闭，务必手动开
用 short 存数组？先看 cache line 和对齐
单个 short 看似省内存，但数组连续访问时，CPU 缓存按 64 字节行加载。如果结构体里混着 short、char、int，编译器插入填充字节，总大小可能反而比全用 int 还大。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：定义
struct { short a; char b; short c; };，sizeof却是 8 而不是 5，因对齐填充 - 实操建议：用
#pragma pack(1)强制紧凑布局前，先用offsetof和sizeof验证内存布局；更稳妥的做法是用std::vector<int16_t></int16_t>，避免手写结构体对齐陷阱 - 性能影响：非对齐访问在 ARM 等架构上可能触发异常或降速；x86 虽容忍，但缓存效率下降明显
short 本身，而是它藏在结构体、序列化、跨平台调用里的那些“看起来没问题”的地方。 
