short 的最小值是 shrt_min，标准保证为 −32768；但不可假设其必为 16 位，因标准仅要求至少 16 位且 sizeof(short) ≤ sizeof(int)。
short 的最小值是 SHRT_MIN，标准保证为 −32768（即 −215）。但别直接写死这个数字——它依赖于实现，且可能不是你真正该用的类型。
为什么不能假设 short 一定是 16 位
C++ 标准只要求 short 至少 16 位，且满足 sizeof(short) 。实际中绝大多数平台确实是 16 位有符号整数，但标准没封死其他可能（比如某些嵌入式环境）。硬写 <code>-32768 会掩盖可移植性风险。
- 用
#include <climits></climits>后直接取SHRT_MIN，这是唯一可移植写法 - 如果需要确定宽度，改用
int16_t（需<cstdint></cstdint>），它明确是 16 位补码，不存在歧义 -
short在不同平台 ABI 中可能对齐方式不同，影响结构体大小，别只盯着范围
short 和 int 混用时的隐式转换陷阱
在算术表达式里，short 会先提升为 int（整型提升规则），这本身没问题；但一旦涉及比较、函数重载或模板推导，就容易出意外。
- 比如
void f(int); void f(long);，传short会调用f(int)，但若改成void f(short)，行为就变了 - 模板如
template<typename t> auto add(T a, T b) { return a + b; }</typename>，传两个short，返回类型是int（不是short），因为加法结果被提升 - 用
static_cast<short>(expr)</short>强制缩窄时，不检查溢出，32768转short是未定义行为
什么时候真该用 short？多数时候其实不该
除非你在处理大量小整数且内存敏感（比如图像像素、音频采样、网络协议字段），否则用 int 更安全、更高效。现代 CPU 对 int 运算通常不比 short 慢，反而可能因对齐或指令选择更优。
立即学习“C++免费学习笔记（深入）”；
- 数组场景：100 万个
short省 2MB 内存，但若后续要频繁转int计算，缓存局部性可能反被破坏 - 函数参数：传
short和传int在 x86-64 ABI 下都用寄存器，无差别；但接口暴露short会限制调用方，比如无法传字面量100000 - 文件/网络序列化：必须用固定宽度类型（如
int16_t），否则跨平台读写出错
真正要注意的不是下限数字本身，而是：是否需要可移植的确定宽度、是否清楚整型提升后果、以及有没有被编译器警告（比如 -Wshorten-64-to-32）忽略过。
