该用 short 仅当与16位二进制协议对齐或大规模内存敏感数组；其余场景优先用 int 或 int16_t——后者语义明确、跨平台安全，避免溢出、对齐陷阱及隐式转换开销。
什么时候该用 short 而不是 int
绝大多数情况下不该主动选 short。它只在两个明确场景下有实际价值：一是和外部二进制协议/硬件寄存器对齐（比如读写某个嵌入式设备的 16 位寄存器），二是大规模数组且内存敏感（比如处理百万级 short 像素值的图像缓冲区）。其他时候用 int 更安全——它至少是 16 位，实际在主流平台（x86/x64）上是 32 位，运算快、无符号扩展隐患少。
常见错误现象：short a = 32767; ++a; 结果是 -32768（溢出未定义行为，但通常回绕）；而 int 在 32 位系统上能撑到 21 亿才溢出，容错空间大得多。
- 别因为“数值小”就选
short——编译器不会帮你省寄存器，反而可能因类型提升多一次零扩展 - 函数参数/返回值尽量不用
short，调用时会隐式转成int，徒增转换开销 - 跨平台代码中，
short保证是 16 位，但int只保证 ≥16 位，所以协议字段必须严格 16 位时才用short
short 在结构体里的内存对齐陷阱
结构体里混用 short 和 int 容易让编译器悄悄插填充字节，导致 sizeof 失控或和 C 接口不兼容。比如：
struct Bad {<br> char a;<br> short b;<br> int c;<br>}; // sizeof 可能是 12（a 占 1 字节，b 占 2 字节，但为了对齐 c，中间补 1 字节，c 占 4 字节，末尾再补 4 字节）
而如果把 short b 换成 char d[2]，大小可能变成 8——不是类型语义变了，是填充规则变了。
立即学习“C++免费学习笔记（深入）”；
- 用
#pragma pack(1)或__attribute__((packed))强制紧凑排列，但会牺牲访问性能 - 更稳妥的做法是按对齐要求排序：从大到小排字段（
int→short→char） - 和 C API 交互时，务必用
static_assert(sizeof(struct X) == N, "size mismatch");校验
std::vector 的性能真相
很多人以为 std::vector<short></short> 比 std::vector<int></int> 节省内存，这没错，但代价常被忽略：现代 CPU 缓存行是 64 字节，short 数组每行能塞 32 个元素，int 只能塞 16 个——看似 short 更密，但很多算法（如求和、归一化）需要逐个加载、转换、计算，short 会触发更多指令（如 movsw 或 cvtdq2ps）和额外的饱和处理。
- 纯存储场景（如离线日志、归档数据）可用
short，但读取后建议立刻转成int再计算 - 用
std::vector<int16_t></int16_t>替代short，语义更清晰，避免平台相关性（某些嵌入式平台short是 32 位） - 若真要极致性能，考虑 SIMD 批量处理（如用 AVX2 一次处理 16 个
int16_t），但这时类型已不是瓶颈，内存带宽和指令调度才是
替代方案：什么时候该用 int16_t 而不是 short
short 的宽度不保证是 16 位（C++ 标准只要求 ≥16），虽然几乎所有桌面/服务器平台都是 16 位，但某些 DSP 或老式嵌入式平台可能不同。int16_t 是 <cstdint></cstdint> 提供的固定宽度类型，不存在歧义。
- 涉及网络字节序转换（
htons/ntohs）时，必须用int16_t或uint16_t，否则short可能在某些平台被当 32 位处理 - 用
auto推导容器元素类型时，std::vector<int16_t>::value_type</int16_t>比short更可读、更稳定 - 头文件依赖上，
int16_t需要显式包含<cstdint></cstdint>，而short是内置类型——这点看似麻烦，实则是提醒你：这里真的需要精确宽度
真正关键的不是“能不能用 short”，而是“有没有人会维护这段代码”。一旦项目跨平台、跨团队，或者未来要对接 Rust/Python 的二进制绑定，int16_t 就不是可选项，是必选项。
