short和long字节大小不固定，仅保证sizeof(short)≤sizeof(int)≤sizeof(long)，跨平台差异大；应优先使用int16_t/int32_t等固定宽度类型，并注意格式符匹配与隐式转换风险。
short 和 long 的字节大小不固定，取决于平台和编译器
它们没有绝对的字节数保证，C++ 标准只规定 sizeof(short) ≤ sizeof(int) ≤ sizeof(long)，实际大小得看你的环境。比如在主流 64 位 Linux/macOS 上：short 通常是 2 字节，int 是 4 字节，long 是 8 字节；而在 Windows 64 位上，long 还是 4 字节（和 int 一样）。这直接导致跨平台代码出问题。
- 用
sizeof(short)、sizeof(long)实际测一测，别凭经验猜 - 如果需要确定宽度（比如网络协议或内存对齐），优先用
int16_t、int32_t、int64_t（需#include <cstdint></cstdint>） -
long在旧代码里常被误当作“一定比 int 大”，但 Win64 下它和int一样宽，容易埋下溢出隐患
printf/scanf 中的格式符必须匹配类型，否则行为未定义
很多人写 printf("%d", my_long_var) 看似能跑，其实错了——%d 对应 int，long 得用 %ld，short 虽然常被提升为 int，但显式传 short 时推荐用 %hd。
-
short x = -1; printf("%hd", x);✅ 安全明确 -
long y = 1000000L; printf("%ld", y);✅ 必须加l -
printf("%d", y);❌ 可能输出乱码或截断，在不同 ABI 下表现不一致 - 用 clang 或 gcc 编译时加
-Wformat（默认开启）能捕获这类错误
算术运算中 short 会自动提升，long 一般不会，但隐式转换仍可能丢精度
short 参与运算前几乎总是被提升为 int（整型提升规则），所以 short a = 30000, b = 30000; short c = a + b; 实际是先转成两个 int 相加，再截断赋给 c——结果不是溢出，而是静默回绕。而 long 虽不提升，但如果把它赋给 int 或传给只收 int 的函数，就可能截断。
- 不要依赖
short的“小范围”来防溢出，它该爆照样爆，只是爆得早 -
long到int的赋值：如int i = some_long_value;，若值超出int范围，结果由实现定义（常见是取低 32 位） - 启用
-Wconversion可警告这类隐式收缩转换
什么时候该用 short，什么时候该用 long？
真实项目里，short 和 long 都不是首选。除非有明确约束，否则直接用 int 最省心；需要更大范围时，优先选 long long（C++11 起保证至少 64 位）或固定宽度类型。
立即学习“C++免费学习笔记（深入）”；
- 用
short：只在大量数组/结构体且内存敏感（如嵌入式、GPU buffer）、且确认值域 ≤ ±32767 时 - 避免用
long：它在 Windows 和 Linux 上语义分裂，接口层、序列化、跨语言调用时极易出错 - 替代方案：
int64_t比long更可靠；size_t用于容器大小，ptrdiff_t用于指针差值——别硬套long
最常被忽略的一点：long 的符号性不明确。它默认是有符号的，但 unsigned long 在 32 位系统上和 size_t 宽度相同，到了 64 位又可能不同。这种“看着像能用，一换平台就崩”的模糊地带，才是实际踩坑最多的地方。
