short int 实际大小不固定，标准仅规定至少16位；x86_64 linux下gcc默认2字节，但嵌入式或老系统可能为4字节或更大；应以sizeof(short int)运行时确认，不可硬编码假设。
short int 在不同平台上的实际大小
它不固定，取决于编译器和目标平台——标准只规定 short int 至少 16 位，但没说必须是 16 位。你在 x86_64 Linux 上用 GCC 编译，默认是 2 字节；但在某些嵌入式 DSP 或老式 16 位系统里，它可能是 4 字节甚至更大。
- 查法最直接：
sizeof(short int)，别猜，运行时看 - 不要依赖
sizeof(short) == 2写跨平台逻辑，比如序列化或网络协议字段对齐 - Windows MSVC、Linux GCC、macOS Clang 在主流 64 位系统下通常都给 2 字节，但这是实现选择，不是保证
short 和 int 的区别不只是“更短”
它们是独立类型，不能假设 short 总比 int 小——虽然绝大多数实现满足 sizeof(short) ，但 C++ 标准只要求 <code>SHRT_MAX ，即值域不超，不强制内存小。
- 在某些 DSP 平台（如 TI C6000），
int是 32 位，short也是 32 位，因为硬件整型单元统一 - 用
static_assert(sizeof(short) == 2, "")可以在编译期卡住不合规平台，但得想清楚 fallback 方案 - 如果真要“小整数”，优先考虑
int16_t（来自<cstdint></cstdint>），它明确保证 16 位且有符号
sizeof(short int) 返回值不是编译常量？
它是编译时常量，但值由目标 ABI 决定，不是语言内建硬编码。所以同一个源码，在 A 平台 sizeof(short) 是 2，在 B 平台可能是 4，而编译器不会报错——只要符合标准。
- 链接时不会检查类型大小一致性：两个 .o 文件若基于不同 ABI 编译，
short大小不一致，可能导致结构体偏移错乱、读写越界 - 头文件中定义含
short的 struct 时，务必搭配#pragma pack或alignas显式控制布局，否则跨模块易出问题 - 模板推导里慎用
short：比如std::vector<short></short>在不同平台缓存行利用率差异大，影响性能
什么时候该用 short int，什么时候不该用
用它的唯一合理理由是：你明确需要恰好那个范围（-32768 到 32767）且在意内存密度，比如处理大量 16 位音频样本或传感器原始数据。
立即学习“C++免费学习笔记（深入）”；
- 别用它替代
int来“省空间”——现代 CPU 对 32 位操作往往比 16 位更快，且可能触发隐式零扩展/符号扩展指令开销 - 函数参数传
short没意义：C++ 调用约定通常提升为int，栈上占的还是 4 字节（或更多） - 日志、调试、配置项里出现
short基本是信号：这里可能本该用uint16_t或enum class，类型语义更清晰
真正容易被忽略的是：short 的符号性在位操作时很危险——short x = -1; x 可能溢出未定义行为，而 <code>int16_t 至少让你意识到自己在做带符号移位。类型大小只是表象，语义和可移植性才是咬人的地方。
