short在算术运算中必定提升为int，这是C++标准强制规定的整型提升规则，与显式转换无关；auto推导、模板参数等均反映提升后的int类型。
short 在算术运算中一定会变成 int
只要参与加减乘除、比较、位运算等表达式，short 会立刻被提升为 int，不是“可能”，是语言标准强制规定。这和你有没有显式写 static_cast 无关，编译器在语义分析阶段就完成了这个转换。
常见错误现象：short a = 32767; short b = 1; auto c = a + b; ——你以为 c 是 short？错，它是 int，值是 32768，但类型早已不是 short。
- 所有二元运算符（
+、&、<<等）左侧或右侧只要有一个short，整个操作数都先提升到int - 函数传参不触发提升：如果函数形参是
short，传short就按值复制，不升；但一旦进了表达式，立刻升 - 数组下标、
sizeof、取地址（&x）这些“非运算上下文”里，short保持原类型
为什么不能靠 short 节省内存又想避免隐式提升
想用 short 存小整数省空间，又怕它总变 int 失去控制权？那得主动切断提升路径。关键不是“怎么让它不升”，而是“在哪让它别进提升上下文”。
使用场景典型如嵌入式寄存器映射、网络协议字段打包、大量结构体数组——这时你真正需要的是“存储时压缩，计算前明确转”。盲目依赖自动提升只会让类型流失去预期。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 对单个
short做自增/自减（a++）：先提升成int计算，再截断回short存储，中间有隐式转换 - 用
static_cast<short>(a + b)强制截断是可行的，但要自己承担溢出风险（32767 + 1 → -32768） - 更安全的做法是：只在存储/IO 层用
short，运算一律用int或std::int16_t并显式检查边界
char、signed char、unsigned char 的提升规则不一样
short 和 char 系列常被混谈，但它们的整型提升行为不同：所有 char 类型（包括 unsigned char）在运算中也升为 int，但前提是 int 能完整表示其值域。在极少数平台（比如 CHAR_BIT == 16 且 INT_MAX == 32767），unsigned char 可能升为 unsigned int ——而 short 永远升为 int，无例外。
性能影响很小，但兼容性上要注意：跨平台代码若假设 sizeof(short) == sizeof(int)，在某些 DSP 或老嵌入式平台会崩；标准只保证 sizeof(short) <= sizeof(int)。
-
short提升目标固定是int，哪怕int是 64 位 -
unsigned short同样升为int，不是unsigned int——除非int表示不下unsigned short全部值（几乎不存在） - 用
std::int16_t替代short可提高可读性，但它仍是typedef到某个内置类型，提升规则不变
模板推导和 auto 会暴露提升结果
这是最容易踩坑的地方：auto 捕获的是提升后的类型，不是原始变量类型。模板参数推导同样如此。你以为在写泛型逻辑，结果底层类型早被悄悄改写了。
示例：short x = 1, y = 2; auto z = x + y; —— z 的类型是 int，不是 short。如果后续传给只接受 short& 的函数，编译失败；若传给接受 const short&，会生成临时 short 对象，但值已截断。
- 用
decltype(x + y)查类型，得到的是int，不是short - 写模板时若依赖
T的大小或符号性，传入short可能因提升导致分支走错（比如特化匹配不到） - 真要保留原始类型语义，得用
std::common_type_t<decltype(x), decltype(y)>，但它返回的是“共同可表示类型”，通常还是int
最易被忽略的一点：这种提升发生在编译期，无法通过运行时检查绕过。你看到的变量名写着 short，但在表达式树里它早就不是了。
