short 通常为16位（-32768~32767），long long 至少64位（约-9.2×10¹⁸~9.2×10¹⁸）；二者量级悬殊，short 易因运算溢出导致未定义行为，仅适用于内存敏感且值域严格受限的场景。
short 和 long long 的位宽与取值范围差异
它们根本不是同一量级的类型，short 通常占 16 位（2 字节），而 long long 至少 64 位（8 字节）——后者能表示的数比前者大上万万亿倍。
常见错误是把 short 当作“节省内存的 int”随意替换，结果在计算中溢出却不报错。比如累加 10000 个 1000，short 在第 33 次就绕回负数了。
-
short：标准要求 ≥16 位，主流平台固定为 16 位；有符号时范围是 -32768 ~ 32767 -
long long：C++11 起强制 ≥64 位，实际在所有现代编译器（GCC/Clang/MSVC）都是 64 位；有符号范围约 -9.2×10¹⁸ ~ 9.2×10¹⁸ - 别依赖
sizeof(short) == 2或sizeof(long long) == 8写死逻辑，用std::numeric_limits查更安全
什么时候必须用 long long 而不能用 short
不是“想存大数才用”，而是当运算中间结果可能越界时，short 会静默截断，且这种截断常发生在隐式提升后——你根本没写强制转换。
典型场景：short a = 30000, b = 30000; auto c = a * b; 这里 c 是 int 类型（因为 short 算术会先提升到 int），但乘积 9 亿已超出 int 的 32 位有符号上限（2147483647），导致未定义行为（UB）。
立即学习“C++免费学习笔记（深入）”；
- 时间戳（如微秒级 Unix 时间）、文件大小（>4GB）、哈希计算中间值，直接用
long long更省心 - 做乘法、平方、累加超过几千次的循环，别赌
short不溢出——它太容易翻车 - 和
std::chrono::duration、off_t、size_t交互时，注意类型对齐，short几乎从不匹配
short 的真实使用场景其实非常窄
它几乎只该出现在内存极度敏感、且数据天然受限的场合，比如嵌入式传感器采样值（-50~50℃ 温度）、音频 PCM 16 位样本、或网络协议里明确定义为 2 字节字段的结构体成员。
一旦离开这些明确约束，用 short 就是在给后续维护埋雷：别人读代码时不会默认你“算过不会溢出”，而 long long 至少让人一眼看出“这数可能很大”。
- 数组批量存储时，
std::vector<short></short>比std::vector<long long></long>省 4 倍内存，但前提是元素值真正在 [-32768, 32767] 内且无计算 - 函数参数传
short没意义——它会被提升为int，接口反而显得意图模糊 - 别用
short当循环变量（for (short i = 0; i ），<code>n稍大就挂
编译器和 ABI 对这两种类型的处理差异
它们在 ABI 层面地位完全不同：short 是“可 promoted 类型”，几乎所有运算前都会被悄悄转成 int；而 long long 是完整的一等公民，支持原生指令（如 x86-64 的 imulq）。
这意味着：对 short 做位操作、比较、甚至取地址，背后都可能多出零扩展（movswl）或符号扩展指令；而 long long 的操作更可预测，但某些老平台（如 32 位 ARM）仍需多条指令模拟 64 位运算。
- 启用
-Wshorten-64-to-32（Clang）或-Wconversion（GCC）能捕获隐式截断，但不会警告short到int的提升——那是标准行为 - 结构体里混用
short和long long会导致填充字节剧增，比如struct { short a; long long b; }在 64 位系统上通常占 16 字节（a后补 6 字节对齐） - 调试时看变量值，
short显示为整数，但寄存器里可能是 32 位寄存器的低 16 位，容易误判
事情说清了就结束。类型选错最麻烦的不是报错，而是跑得通却算错——尤其当 short 溢出后参与后续逻辑，或者 long long 被意外截断进 int 参数，这种 bug 往往要靠输入边界值才能触发。
