short int 的最小负数值为−32768，即 SHRT_MIN 宏定义的值；其实际值取决于平台位宽与补码表示，不可硬编码字面量，应使用 SHRT_MIN 或 int16_t 保证跨平台安全。
short int 的最小负数值取决于有符号性与位宽
默认的 short int 是有符号类型，标准要求至少 16 位，主流平台（x86/x64/ARM）实际就是 16 位，采用二进制补码表示。此时最小值是 −32768，即 SHRT_MIN 宏定义的值。
别直接写 -32768 做字面量——它在某些上下文里会被解析为一元负号加 32768，而 32768 超出 short 正数范围（最大 32767），触发实现定义行为或编译警告。
- 始终用
SHRT_MIN（需包含<climits>） - 若手动计算，确认平台
sizeof(short) == 2，且CHAR_BIT == 8 - 嵌入式平台可能不同：有些 DSP 或旧单片机上
short是 24 位或 32 位，SHRT_MIN会随之变化
为什么不能假设 short 一定是 16 位
C++ 标准只规定 short 至少和 char 一样宽，且不大于 int；它不保证位数。虽然几乎所有通用平台都实现为 16 位，但依赖这点会让代码在 DSP、RISC-V 某些配置或定制工具链下出错。
- 查证方式：打印
sizeof(short) * CHAR_BIT - 跨平台安全写法：用
int16_t（需<cstdint>）替代，它明确是带符号 16 位整数 -
short和int16_t不等价：前者可移植性弱，后者有确定语义但可能不存在（如果平台无原生 16 位支持，int16_t就不定义）
常见错误：把 -32768 当作字面量传给函数
比如写 foo(-32768)，而 foo 参数是 short，这看似合理，实则危险：
立即学习“C++免费学习笔记（深入）”；
- 编译器可能先将
32768解释为int字面量（合法），再执行负号运算，最后隐式截断为short - 该过程不报错，但属于“实现定义转换”，不同编译器或优化级别下结果可能不一致
- 更糟的是，若函数重载了
int和short版本，-32768可能意外匹配到int版本
正确做法：foo(static_cast<short>(SHRT_MIN)) 或直接传 SHRT_MIN（它本身是 short 类型常量）。
signed short 和 unsigned short 的下限差异
short 默认等价于 signed short，下限是负数；而 unsigned short 下限恒为 0，上限翻倍（65535）。二者底层存储可能相同，但语义和运算规则完全不同。
- 混用会导致静默整数提升：如
unsigned short a = 1; short b = -2; auto c = a + b;→c是int，值为 −1，但容易误判溢出逻辑 - 比较时尤其危险：
unsigned short x = 0; short y = -1; if (x > y)→y被提升为unsigned short，变成 65535，条件为真 - 没有“无符号 short 的最小负数”——它根本不存在，下限只能是 0
真正要注意的不是数字本身，而是你是否在代码里隐含假设了位宽、符号性或字面量解析顺序。这些地方一旦写死，改平台时最容易突然崩。
