short不保证是16位，因C++标准仅规定sizeof(short)≥sizeof(char)且≤sizeof(int)，未强制其为16位；跨平台或安全关键场景中不可无条件等同int16_t。
不一样，但绝大多数常见平台上效果等价——前提是不跨平台、不写安全关键代码。 你不能无条件把 short 当作 int16_t 用，尤其在嵌入式、通信协议或二进制序列化场景里。
为什么short不保证是16位
C++ 标准只要求 sizeof(short) ，且 <code>short 至少能表示 -32768 到 32767（即 ≥16 位有符号整数）。它没规定必须是 16 位。
- 主流 x86/x64 和 ARM64 平台：
short确实是 2 字节、16 位，范围 -32768 ~ 32767 - 某些 DSP 或老旧嵌入式平台：
short可能是 24 位甚至 32 位 -
int16_t是 C99/C++11 引入的“精确宽度类型”，定义在<cstdint></cstdint>中，**只有当平台原生支持 16 位整型时才存在**；否则该类型根本不会被定义（编译失败）
什么时候必须用int16_t而不是short
当你需要确定的二进制布局、网络字节序交换、内存映射 I/O 或与硬件寄存器对齐时，short 的“可能不精确”会直接导致 bug。
- 读写文件头或网络包字段（比如某协议规定“第4–5字节为带符号16位整数”）→ 必须用
int16_t - 结构体用于
memcpy或reinterpret_cast→short在不同编译器可能有填充差异，int16_t更可控 - 静态断言验证宽度：
static_assert(sizeof(int16_t) == 2, "int16_t must be 2 bytes");—— 这种检查对short没意义，因为标准允许它更大
short和int16_t混用的坑
表面看都能存小整数，但隐式转换和溢出行为在边界上可能咬人。
立即学习“C++免费学习笔记（深入）”；
- 把超范围的
int值赋给short是未定义行为（UB），而赋给int16_t同样是 UB —— 但前者更容易被编译器静默接受 - 混合运算：
short a = 32767; int16_t b = 1; auto c = a + b;→a会先整型提升为int，结果是int类型，不是int16_t；若你预期截断，得显式强转 - 格式化输出：
printf("%hd", s);对short正确，但对int16_t要用%" PRId16（需<inttypes.h></inttypes.h>）或统一转成int再打
真正要命的地方不在日常开发，而在你换了一款 MCU、切到 WASM、或者同事在 macOS 上交叉编译后，发现结构体大小变了、网络包解析错位了——这时候翻出 short 和 int16_t 的区别，就不是“科普”而是救火了。
