Java自动类型提升规则为：小于int的整型运算先升为int；混合类型按最宽类型对齐；方法重载优先最小必要升级；字面量常量有窄化赋值特例，变量运算则严格升宽。
Java 中的自动类型提升（Implicit Type Promotion）常在表达式中“悄悄发生”，尤其当操作数类型不一致时，编译器会按规则向上转型为更宽的类型——你没写强制转换，它却已替你做了，还可能带来意料之外的结果。
算术运算中的隐式升级最常见
只要表达式中存在 byte、short、char 与 int 或更宽类型混合运算，它们会先被提升为 int（哪怕两边都是 byte）：
byte a = 10, b = 20; byte c = a + b; // 编译错误！a+b 实际是 int 类型，不能直接赋给 byte
这里看似两个 byte 相加，但 Java 规定：所有小于 int 的整型（byte/short/char）在算术运算中一律提升为 int。所以 a + b 结果是 int，无法直接赋值给 byte c，必须显式强转：byte c = (byte)(a + b);
混合类型运算时，向“最宽类型”看齐
当不同基本类型参与同一表达式，结果类型由“最宽的那个”决定。顺序是：
byte/short/char → int → long → float → double
-
int + long→ 结果是long -
short + float→ 先升为int，再升为float，结果是float -
char + byte→ 两者都升为int，结果是int
这种链式提升容易被忽略，比如用 char 做计数器参与计算，结果却变成 int，后续若误当作 char 处理（如用于字符串索引或字符比较），逻辑就可能出错。
立即学习“Java免费学习笔记（深入）”；
方法重载时，提升可能绕过你的预期
调用重载方法时，如果找不到参数完全匹配的版本，编译器会尝试用自动提升“凑合”：
void foo(int x) { System.out.println("int"); }
void foo(long x) { System.out.println("long"); }
foo((short)5); // 输出 "int" —— short 被提升为 int，而非 long
即使有 long 版本，short → int 是更“近”的提升路径（属于 widening primitive conversion），所以优先选 int 版本。你以为传了小类型会触发更“大”的重载？其实它只走最小必要升级。
字面量和变量混用，提升时机易混淆
整数字面量默认是 int，浮点字面量默认是 double。这会让看似对称的表达式行为不对称：
-
short s = 10 + 20;✅ 编译通过 —— 因为10和20是 int 字面量，但整个表达式是编译期常量，且值在 short 范围内，JVM 允许窄化赋值 -
short s1 = 10; short s2 = 20; short s3 = s1 + s2;❌ 编译失败 —— 此时s1 + s2是运行期计算，按规则升为 int，不再享受常量优化
这种差异让代码行为依赖“是否为字面量”，稍一重构（比如把字面量提成变量），原本能过的代码就报错。
