short 和 long long 的内存大小不固定，仅保证 short 至少 2 字节、long long 至少 8 字节；实际大小取决于编译器和平台，应使用 sizeof 运行时确认。
short 和 long long 的实际内存大小不固定，取决于编译器和平台
它们的字节数不是 C++ 标准硬性规定的，而是有最小保证：short 至少 2 字节，long long 至少 8 字节。常见情况下，x86_64 Linux/macOS 下 short 是 2 字节，long long 是 8 字节；但嵌入式平台（如某些 ARM Cortex-M）可能让 short 占 4 字节，而 long long 仍为 8 字节。
别靠“常识”猜大小，运行时用 sizeof 看：
std::cout << sizeof(short) << "\n"; // 可能输出 2 或 4 std::cout << sizeof(long long) << "\n"; // 通常输出 8，但理论上可更大
- 用
std::numeric_limits<t>::min()</t>/::max()查可用范围，比记字节更可靠 - 跨平台项目里，
int16_t/int64_t比short/long long更明确——前者来自<cstdint></cstdint>，强制宽度 -
short在多数现代桌面系统上几乎没性能优势：CPU 通常按 4 或 8 字节对齐/加载，存short反而可能触发额外的读-改-写操作
赋值或函数传参时，short 和 long long 会悄悄转换类型
当你把一个 int 值赋给 short，或把 short 传给期望 int 的函数（比如 printf("%d", s)），C++ 会自动做整型提升（integer promotion）——short 总是先转成 int 再参与运算；long long 则一般保持原类型，除非显式转换。
- 这导致
short a = 32767; a++;可能溢出（变成 -32768），但a + 1表达式的类型已经是int，不会在加法阶段溢出 - 用
printf打印short必须写%hd，写%d是未定义行为（参数类型不匹配）；long long对应%lld - 模板推导中，
short会被升为int，所以auto x = short{5};推出的是int，不是short
struct 里混用 short 和 long long 容易踩内存对齐坑
结构体成员排列受对齐规则影响：short 通常要求 2 字节对齐，long long 要求至少 8 字节对齐。如果顺序不当，编译器会在中间插入填充字节，让总大小远超各字段之和。
立即学习“C++免费学习笔记（深入）”；
struct Bad {
char a; // offset 0
short b; // offset 2 → 但前面只有 1 字节，要补 1 字节 padding → offset 2
long long c; // offset 8 → 因为 long long 需 8 字节对齐，前面只到 4，补 4 字节 → offset 8
}; // sizeof(Bad) == 16，不是 1+2+8=11
- 把大类型放前面、小类型放后面，能减少填充：比如
long long c; short b; char a;，sizeof可能压到 16 或更小（取决于平台） - 用
alignas强制对齐可能适得其反——它只增大对齐要求，不减小填充 - 需要紧凑布局时，用
#pragma pack(1)或[[gnu::packed]]，但会牺牲访问性能，且某些平台不支持未对齐访问
什么时候该选 short，什么时候必须用 long long
选 short 的理由非常窄：仅当你明确控制内存带宽（比如网络协议字段、GPU 缓冲区、嵌入式传感器数据流），且确认所有端都按相同宽度解释，并接受它只有 ±32767 的范围。
long long 几乎只在一种场景不可替代：需要 >2³¹ 的整数（比如时间戳纳秒值、大文件偏移量、密码学中间值），且你不能用 int128_t 或第三方大数库。
- 普通计数、数组索引、循环变量，用
int或size_t就够了，别为了“省 2 字节”选short -
long long运算在部分老 CPU 上比int慢，但现代 x86_64 和 ARM64 基本无差别 - 如果你看到别人用
short存字符——那是错的，用char或uint8_t；用short存布尔——更是错的，用bool
真正麻烦的从来不是“哪个更大”，而是“谁在哪儿悄悄变了类型”和“结构体里多出来的那几个字节到底从哪来”。
