short int 在64位系统上占2字节；标准规定其至少16位，实际几乎总是16位（2字节），与系统位数无关，由C++标准和ABI共同约束，而非CPU寄存器宽度。
short int 在 64 位系统上占多少字节？
它不因系统是 32 位还是 64 位而改变：标准规定 short int 至少 16 位，实际几乎总是 16 位（即 2 字节）。你用 sizeof(short) 查，结果基本是 2，不管编译器跑在 x86-64 还是 ARM64 上。
原因很简单：short 的大小由 C++ 标准和 ABI（如 System V AMD64 ABI 或 Microsoft x64 ABI）共同约束，而非 CPU 寄存器宽度。64 位系统照样能高效处理 16 位数据，没必要扩大它。
- 别靠“64 位=所有类型都变大”去猜——
int在多数 64 位平台仍是 4 字节，long才可能变（Linux 是 8 字节，Windows 是 4 字节） - 如果你真看到
sizeof(short) == 4，那大概率是嵌入式特殊平台或自定义编译器，不是主流桌面/服务器环境 - 依赖具体大小的代码（比如序列化、内存映射）必须用
int16_t而非short，因为前者才保证恰好 16 位
为什么 sizeof(short) != sizeof(int) != sizeof(long)？
因为 C++ 标准只规定了最小宽度和相对顺序：sizeof(char) ，且 <code>char 必为 1 字节。其余全由实现决定。
这导致跨平台时行为不一致：
立即学习“C++免费学习笔记（深入）”；
- Linux x86_64：
short=2,int=4,long=8 - Windows x64：
short=2,int=4,long=4（注意：这里long没变） - ARM64 macOS：
short=2,int=4,long=8
所以写 long x = 0x123456789ABCDEF0LL; 在 Windows 上没问题，在 Linux 上也行；但若你用 long 存文件偏移或指针差值，就可能在 Windows 上溢出（最大约 2GB），而在 Linux 上撑到 8EB。
什么时候该用 short，什么时候该用 int16_t？
用 short 只有一个合理场景：你明确想利用其“至少 16 位且通常最小”的特性来节省内存，并接受它可能不是精确 16 位（虽然现实中极少见）；其他所有需要确定宽度的地方，必须用 int16_t 或 uint16_t。
- 网络协议字段、二进制文件格式、硬件寄存器映射——一律用
int16_t，否则在不同平台读写会错位 - 数组缓存优化（比如百万级
short数组比int节省一半内存）——可用short，但得确认目标平台确实为 2 字节，且编译器没做奇怪对齐 - 函数参数或返回值中暴露
short——小心整型提升：传short给可变参函数（如printf("%hd", s)）必须显式用%hd，否则会被升为int导致截断或乱码
常见误判：sizeof(short) == sizeof(void*)？
完全不等。指针大小取决于地址空间宽度，short 大小取决于整数 ABI 设计。在 64 位系统上：sizeof(void*) 几乎总是 8，而 sizeof(short) 几乎总是 2。两者毫无关系。
这个误判常出现在刚学指针的人身上，以为“地址是 64 位，所以所有整数类型都该是 64 位”，其实编译器会按需选择最经济的类型——short 存温度、年份、状态码足够了，没必要拉到 8 字节。
真正要注意的是：别在结构体里混排 short 和指针，否则可能因对齐填充浪费空间。例如：
struct Bad {
short a; // offset 0
void* p; // offset 8（因对齐要求跳过 6 字节）
};
这种布局会让 sizeof(Bad) 变成 16，而不是直觉上的 10。调整顺序或加 [[alignas(2)]] 才能控制。
