short 和 int 是两种不同整型：short 固定 2 字节，int 通常 4 字节；short 适用于内存敏感、协议对齐或范围明确场景，但有符号溢出为未定义行为。
short 和 int 在绝大多数现代 C++ 编译器（GCC/Clang/MSVC）和主流平台（x86/x64 Windows/Linux/macOS）上，是两种明确不同的整型：前者固定占 2 字节（sizeof(short) == 2），后者通常占 4 字节（sizeof(int) == 4）。这不是“可能”，而是你运行代码就能验证的事实。
sizeof(short) 和 sizeof(int) 在实际项目中几乎总是不等
虽然 C++ 标准只要求 sizeof(short) ，但现实中：<br>– <code>short 几乎总为 16 位（-32768 ~ 32767）；
– int 几乎总为 32 位（-2147483648 ~ 2147483647）；
– 你可以直接写 static_assert(sizeof(short) == 2); 和 static_assert(sizeof(int) == 4);，在 x86/x64 上基本不会失败。
容易踩的坑：
– 在嵌入式或旧系统（如某些 DSP 或 16 位单片机）上硬套这个假设，结果 int 是 2 字节，导致结构体对齐错乱或序列化失败；
– 用 sizeof(int) 去算网络协议缓冲区长度，却没考虑接收端可能是 16 位平台。
short 参与算术运算时会自动提升为 int
C++ 的整型提升规则规定：所有小于 int 的有符号类型（包括 short）在参与表达式计算前，都会先隐式转为 int。这意味着：
– short a = 30000, b = 30000; auto c = a + b; 中，c 的类型是 int，值是 60000（不会溢出）；
– 但如果你写 short c = a + b;，编译器会先算出 60000（int），再截断赋给 short → 结果是未定义行为（UB），实际常得 -5536；
– 这也是为什么 for (short i = 0; i 很危险：当 <code>n > 32767 时，i 加到 32767 后再加 1 就变成 -32768，循环永不停止。
short int 就是 short，别被语法迷惑
short int、signed short、short 在语义和 ABI 上完全等价，sizeof 和 alignof 结果一致。常见误解：
– 认为 short int x = 40000; 比 short x = 40000; “更安全”或“范围更大”——其实都溢出；
– 在模板参数或函数重载中混用 short 和 unsigned short，结果因符号性不匹配而调不到预期重载；
– typedef 里写 using small_id = short int;，纯属冗余，反而降低可读性。
立即学习“C++免费学习笔记（深入）”；
什么时候该选 short 而不是 int
选 short 不是为了“省两个字节显得高效”，而是为了显式约束 + 协议对齐：
– 结构体中有成百上千个字段（比如 struct Point { short x, y, z; } samples[10000];），用 short 可让整个数组省内存约 50%；
– 对接硬件寄存器、BMP/PNG 文件头、Modbus 协议等明确定义为 16 位字段的场景；
– 数据范围绝对可控（如温度 -200~+200、ADC 采样值 0~4095），用 short 能靠类型本身挡住误传大值；
反例：
– 用户 ID、毫秒时间戳、容器 size、循环计数器上限未知——这些一律用 int 更稳妥。
真正容易被忽略的是溢出行为：有符号 short 溢出是未定义行为（UB），不是“自动回绕”。哪怕当前 GCC 编译出来是 -32768，也不能依赖——开启 -fsanitize=undefined 就会当场报错。如果你需要确定的模运算，必须显式用 static_cast<unsigned short></unsigned> 或 std::modulo（C++26）等手段处理。
