short 至少 16 位（≥2 字节），常见为 2 字节但嵌入式平台可能为 4 字节；long 至少 32 位（≥4 字节），windows x64 上为 4 字节，linux x64 上为 8 字节；跨平台应优先使用 int16_t/int32_t 等固定宽度类型。
short 和 long 在不同平台上的实际大小是多少
它们没有固定字节数，只由标准规定最小范围，具体占多少内存完全看编译器和目标平台。别硬背“short 是 2 字节”，那是 x86-64 Linux 下的常见情况，不是真理。
-
short至少 16 位（≥2 字节），常见为 2 字节，但某些嵌入式平台可能是 4 字节 -
long至少 32 位（≥4 字节），在 Windows x64 上仍是 4 字节，但在 Linux x64 上是 8 字节 - 用
sizeof(short)和sizeof(long)实测最靠谱，别信文档里的“通常” - 跨平台项目里，如果依赖
long是 4 字节，Linux 上一编译就溢出或逻辑错
为什么 int 不写成 short 或 long 却更安全
因为 int 的设计本意就是“自然字长”——编译器挑当前平台最高效处理的整数类型。它不保证大小，但保证效率和 ABI 兼容性。
- 在 32 位系统上，
int通常是 4 字节；在 16 位单片机上，它可能真是 2 字节 - 硬写
short可能导致隐式提升：比如short a = 30000, b = 30000; auto c = a + b;，c是int，不是short，容易误判范围 -
long在 Windows 和 Linux 上行为分裂，传参、序列化、结构体对齐都可能出问题 - 需要确定宽度时，优先用
int16_t/int32_t这类固定宽度类型，头文件是<cstdint></cstdint>
什么时候必须用 short 或 long
极少。基本只出现在对接外部约束的场景，比如二进制协议、硬件寄存器定义、旧 C API 接口。
- 读写某设备要求“字段占 2 字节有符号整数” → 用
int16_t，不是short（后者不保宽度） - 调用 Win32 API 的
LONG类型 → 它是long，但本质是 typedef 的 32 位整数，Windows 上恰好匹配；换到其他平台就得重定义 - 结构体用于 mmap 或网络包，需严格控制布局 → 用
static_assert(sizeof(MyStruct) == X)锁死，别靠short/long猜 - 性能敏感循环里想省 cache 行？先 profile。盲目换
short可能因对齐反而变慢（例如数组中每 2 个short中间插 padding）
常见错误：把 sizeof(short) == 2 当成可移植假设
这是最隐蔽的坑。代码在本地跑得飞起，CI 在 ARM64 或 RISC-V 上直接挂掉。
立即学习“C++免费学习笔记（深入）”；
- 错误示例：
char buf[sizeof(short)]; memcpy(buf, &x, sizeof(short));—— 如果short在目标平台是 4 字节，buf就溢出 - 结构体里混用
short和long，没加#pragma pack或alignas，不同平台 padding 位置不同，序列化失败 - 模板特化按
sizeof(T) == 2分支，结果T = short在某平台是 4 字节，走错分支 - 真正可移植的写法：用
std::numeric_limits<short>::digits</short>查位宽，或直接上int16_t
宽度不确定的类型，永远要配合 sizeof、static_assert 或固定宽度类型一起用。靠经验猜，迟早翻车。
