short在流程控制中一律提升为int，因jvm字节码强制要求；运算结果为int，不可直接赋值给short，需显式强转并校验范围。
掌握 short 类型在流程控制语句中的自动类型转换，关键不是背规则，而是看清“它什么时候被提升、提升成什么、为什么不能直接回填”。short 本身不参与隐式运算结果赋值，流程控制（如 if、for、while）中真正起作用的，是它在表达式里被悄悄升为 int 后的行为。
short 在条件表达式中一律升为 int
Java 规定：所有 byte、short、char 在参与算术或关系运算时，**无论上下文是否是流程控制**，都会被统一提升为 int。这不是语法糖，是 JVM 字节码层面的强制行为。
- if (s1 + s2 > 100) —— s1 和 s2 都是 short，但 s1 + s2 的结果类型是 int，不是 short
- for (short i = 0; i
- while (s != 0) —— s 是 short，但比较操作符 != 两边都按 int 处理，等价于 (int)s != 0
赋值边界：字面量可隐式收缩，变量运算不可逆
编译器对 short 的“宽容”只发生在**右侧为编译期常量且不越界**时，它会自动补上 (short) 强转；一旦涉及变量或运行时计算，就不再兜底。
- short s1 = 5 + 8; ✅ 编译通过 —— 常量表达式，javac 直接算出 13，再检查是否在 -32768~32767 内
- short s2 = s1 + 1; ❌ 编译失败 —— s1 是变量，s1 + 1 结果为 int，不能直接赋给 short
- if (s1 == 100) ✅ 没问题 —— == 是关系运算，s1 被提升为 int 后比较，不涉及赋值
流程控制中容易踩坑的典型场景
看似简单的循环或判断，因 short 提升逻辑不清晰，常导致编译错误或逻辑偏差。
- for 循环自增失效：short i = 0; for (; i
- switch 不接受 short 运算结果：switch(s1 + s2) ❌ 错误 —— case 表达式要求是 char/byte/short/int/枚举/字符串，但 s1 + s2 是 int，虽类型匹配，却因可能溢出被编译器拒绝（需确保是常量才允许）
- 三元运算返回类型陷阱：short a = 1, b = 2; int x = (a > b) ? a : b; ✅ 正确 —— a 和 b 都被提升为 int，整个表达式结果是 int；但 short y = (a > b) ? a : b; ❌ 编译失败，不能把 int 结果直接赋给 short
安全写法建议
想在流程控制中稳妥使用 short，核心原则是：**让提升自然发生，避免强行缩容；需要 short 结果时，显式强转并确认范围。**
- 循环计数优先用 int，除非明确处理海量 short 数组（内存敏感场景）
- 涉及加减运算后要存回 short，务必加 (short)：s = (short)(s + 1);
- 判断逻辑中直接用 short 变量没问题，但别依赖它的“小范围特性”做边界假设（比如 if (s == 32767) 后执行 s++，实际会变成 -32768）
- 调试时可用 Integer.toHexString((int)s) 查看 short 提升后的 int 值，避免符号扩展误解
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
