short 仅在内存敏感且值域明确受限时才比 int 更合适：如嵌入式寄存器映射、同构小整数数组、序列化协议强制16位等场景；否则因整型提升、指令开销和填充问题，反而降低性能与安全性。
什么时候 short 真的比 int 更合适？
只在内存敏感且值域明确受限时才用 short。现代 CPU 对 int 的运算效率通常更高，short 不是“更轻量”的默认替代品。
常见误用场景：想“省点内存”就全局把计数器换成 short——结果可能反而变慢，还埋下溢出隐患。
- 嵌入式系统中驱动寄存器映射（如硬件要求 16 位字段对齐）
- 大量同构小整数数组（如图像灰度缓存、音频采样缓冲区），且确认值恒在
-32768～32767内 - 序列化协议或文件格式规范强制字段为 16 位（如某些二进制日志、网络包头）
short 在不同平台上的实际大小和符号性
short 只保证至少 16 位，但 C++ 标准没规定它必须是 exactly 16 位，也没规定是否默认有符号——不过所有主流编译器（GCC/Clang/MSVC）都实现为 signed short 且占 2 字节。
但别依赖这点：比如某些 DSP 或老嵌入式平台可能不同；更关键的是，sizeof(short) 和 sizeof(int) 在部分 64 位系统上相等（都是 4），此时用 short 毫无空间优势。
立即学习“C++免费学习笔记（深入）”；
- 检查方式：运行时用
sizeof(short)和std::numeric_limits<short>::max()</short> - 跨平台项目中，优先用
int16_t替代裸short，语义清晰且大小确定 - 不要写
short x = -1;然后假设它能安全传给只接受unsigned short的 API
函数参数和返回值里用 short 的坑
传参时 short 几乎总会被整型提升（integer promotion）为 int，所以形参写 void f(short x) 和 void f(int x) 在调用开销上没区别，还可能掩盖类型意图。
更麻烦的是重载歧义：void g(short) 和 void g(int) 同时存在时，字面量 5 会优先匹配 int 版本，而 static_cast<short>(5)</short> 才走 short 版——这容易引发意料外的重载选择。
- 参数尽量用
int或具体语义类型（如PortNumber别名） - 返回值避免
short：调用方很可能直接参与算术运算，提升后反而让类型流失去控制 - 如果 API 协议强制要求 16 位输入，用
int16_t并加注释说明边界约束
性能影响：不是越小越快
在 x86-64 或 ARM64 上，CPU 寄存器是 64 位的，操作 short 往往需要额外的截断（movzx）或符号扩展指令，而 int（通常 32 位）能直接进寄存器运算。
缓存层面也未必受益：结构体里混用 short 和 int 可能导致填充（padding）更多；只有当整个数组全是 short 且访问密集时，局部性提升才可能抵消指令开销。
- 用
std::vector<short></short>存 10 万个数？先测 cache miss rate，别只看内存占用 - 循环中频繁做
short += something—— 每次都隐式转int再截回，不如直接用int - 调试时看到
short变量显示异常？可能是 GDB 读取了高位垃圾值，本质是未定义行为（UB）前兆
真正要纠结 short 的地方，往往不在“该不该用”，而在“怎么让它的边界约束不被绕过”。比如用 class SmallInt { short v; }; 封装并禁用隐式转换，比裸用 short 更可靠。
