short 的取值范围通常为 −32768 到 32767，因主流平台采用16位二进制补码表示；最小值为−32768是因符号位占用1位、剩余15位数值位导致负数比正数多一个；应使用 SHRT_MIN/SHRT_MAX 或 std::numeric_limits::min()/max() 替代硬编码以确保可移植性与安全性。
short 的取值范围由编译器和平台决定，但绝大多数情况下是 −32768 到 32767
标准 C++ 只规定 short 至少 16 位宽，没硬性指定必须是二进制补码或具体上下界。但所有主流平台（x86/x64/ARM）都用二进制补码，且 sizeof(short) 通常为 2 字节 —— 这意味着它实际能表示的整数范围是 −215 到 215−1，即 −32768 到 32767。
你不能靠“记住数字”来写健壮代码，得靠标准头文件：
-
#include <climits></climits>后可用SHRT_MIN和SHRT_MAX -
#include <limits></limits>后可用std::numeric_limits<short>::min()</short>和max()
为什么 -32768 是最小值，而不是 -32767？
因为有符号整数用最高位当符号位，剩下 15 位表示数值。补码下，全 0 是 0，全 1 是 −1，而 1000000000000000（16 位）被定义为 −32768 —— 它没有对应的正数形式（+32768 超出 15 位能表示的最大正数 32767），所以负数比正数多一个。
常见误解是认为对称，比如以为最小值是 −32767；实际只要 short 是 16 位补码，就一定是 −32768 开始。
立即学习“C++免费学习笔记（深入）”；
跨平台时别硬写 -32768，用 SHRT_MIN 更安全
虽然现实中几乎不会遇到非 −32768 的 short 最小值，但 C++ 标准允许更宽的 short（比如某些嵌入式平台支持 32 位 short）。硬编码会埋下隐患：
- 直接写
-32768：可能触发编译警告（字面量超出int范围时先被解析为int，再转成short） - 用
SHRT_MIN：类型精确、无警告、语义清晰 - 用
std::numeric_limits<short>::min()</short>：支持模板泛型，可随类型自动适配
示例：
short x = SHRT_MIN; // ✅ 推荐<br>short y = -32768; // ⚠️ 可能警告，且不具可移植性
short 溢出不是未定义行为？错，它是未定义行为
很多人以为 short 加法溢出就像 unsigned 类型那样“自动回绕”，但 C++ 对有符号整数溢出的定义非常明确：未定义行为（UB）。编译器可以假设它不会发生，并据此做激进优化。
-
short a = SHRT_MAX; a++;→ UB，结果不可预测（不只是“变成 −32768”） - 即使你在调试器里看到它绕回来了，也不能依赖 —— 同一代码换优化等级可能崩溃或逻辑错乱
- 需要回绕语义时，应显式转换为
unsigned short再运算，或用std::clamp/ 条件判断截断
short 的边界值看似简单，但硬编码、忽略补码细节、误判溢出性质，这三处最容易在长期维护或跨平台迁移时出问题。 
