short 在现代 C++ 中几乎不值得主动选用，因其平台依赖性强、隐式转换风险高、性能无优势、二进制兼容性差，且内存节省效果常被对齐填充抵消；仅适用于对接 C 外部接口、显式控制 2 字节序列化、或资源极度受限的嵌入式场景。
为什么 short 在现代 C++ 中几乎不值得主动选用
绝大多数场景下，short 不是更“节省内存”的明智选择，而是引入隐式转换风险和平台依赖的麻烦源头。
它在 x86-64 和主流 ARM 平台上通常仍是 16 位，但标准只要求 ≥16 位；真正决定大小的是 ABI（比如 Windows LLP64、Linux LP64），而非编译器或你写的代码。更关键的是：CPU 对 16 位整数的算术操作往往不比 int 快——现代 CPU 的通用寄存器是 32 或 64 位，读写 short 反而可能触发额外的截断或零扩展指令。
-
short无法保证跨平台二进制兼容（比如网络协议或文件格式中硬编码short，在不同字节序或对齐要求的设备上会出错） - 与
int混用时极易触发隐式提升：short a = 30000; short b = 30000; auto c = a + b;→c是int，不是short，且已溢出 - STL 容器（如
std::vector<short></short>）不减少 cache 压力——对齐和 padding 往往让实际内存占用和int相当
short 真正该用的三个具体场景
它不是“错误”，只是适用面极窄；只有当需求明确锁定这三点时，才考虑它。
- 与 C 风格外部接口对接：比如调用
read()系统调用时传入ssize_t*不行，但某些硬件驱动头文件定义了struct reg { short val; };，此时必须用short保持内存布局一致 - 显式控制二进制序列化尺寸：例如实现一个固定 2 字节字段的协议包，且已确认所有端点都用相同 ABI 和字节序，这时用
int16_t（来自<cstdint>）比裸short更安全 - 嵌入式资源极度受限环境（如 8KB Flash 的 MCU）：仅当 profiling 确认数组大小是瓶颈，且编译器未做自动压缩（如
__attribute__((packed))失效）时，才把int数组换成short—— 但先检查是否能换用 bitset 或状态机压缩
short vs int16_t：别再靠猜来选
它们不是等价替代品。short 是编译器定义的类型，int16_t 是可移植性契约。
立即学习“C++免费学习笔记（深入）”；
-
short在某些 DSP 或老嵌入式平台可能是 24 或 32 位；int16_t要么存在（精确 16 位有符号），要么根本不存在（编译失败），不会静默降级 - 头文件差异：
short无需 include；int16_t必须#include <cstdint>，否则编译报错‘int16_t’ was not declared in this scope - 模板推导行为不同：
auto x = int16_t{5};推出int16_t；auto y = short{5};在某些上下文中可能被提升为int（尤其作为函数参数时）
容易被忽略的对齐陷阱：sizeof(short) ≠ 实际结构体偏移
即使 sizeof(short) 是 2，它在 struct 里仍可能因对齐规则被填充到 4 字节边界。
struct A {
char c;
short s; // 实际偏移可能是 2（紧凑）或 4（对齐到 2 字节边界）
int i;
};
结果取决于编译器默认对齐设置和是否加了 #pragma pack。调试时若发现 offsetof(A, s) 不等于 1，别急着改代码——先查 _Alignof(short) 和目标平台 ABI 文档。
真正需要确定内存布局时，永远用 static_assert(std::is_standard_layout_v<T>) + offsetof 校验，而不是依赖 sizeof 推断。
用 short 的时候，从来不是因为它“小”，而是因为你已经看过了汇编输出、测过了 cache miss rate、并确认了所有协作模块的 ABI 文档。
