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