Java中byte、short、char运算时自动提升为int，是因JVM指令集限制：字节码仅提供iadd、ladd、fadd、dadd等指令，无badd、sadd、cadd，故必须提升至int执行。
Java算术表达式中，byte、short、char操作数自动提升为int，不是编译器“好心帮忙”，而是JVM指令集限制下的强制行为——底层没有对应的小类型算术指令，只能走int通路。
JVM字节码层面没有badd、sadd、cadd指令
Java虚拟机只定义了针对int、long、float、double的算术指令，比如
- 当你写
byte b1 = 1, b2 = 2; int r = b1 + b2;，编译后实际生成的是iload_1（加载b1为int）、iload_2（加载b2为int）、iadd（用int指令相加） - char同理：'A' + 1 实际是把字符的Unicode值（65）当作int加载，再执行iadd
- 这个提升发生在字节码生成阶段，属于编译期硬性规则，和运行时无关
提升不是为了“变大”，而是为了统一运算契约
Java设计者选择int作为整数运算的“最小公共接口”，原因很实在：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 避免溢出风险：两个byte最大值127相加得254，已超出byte范围；提升到int后能完整容纳结果，不丢失中间值
- 匹配硬件习惯：主流CPU对32位整数运算最高效，JVM直接复用这一优势
- 简化语义模型：不用为每种小类型设计独立的运算逻辑和类型检查路径
提升发生在表达式求值过程，与变量声明无关
提升只作用于参与当前运算的操作数本身，不改变变量原始类型，也不影响其他上下文：
立即学习“Java免费学习笔记（深入）”；
-
byte b = 5;中b仍是byte类型；但b + 3里，b被临时当作int参与计算 - 方法参数传递时也会触发：调用
foo(byte b)传入short s，s先升为int再传，但foo内部接收的还是byte（需显式转换传参） - 复合赋值如
b += 3之所以合法，是因为编译器将其重写为b = (byte)(b + 3)，隐含窄化，而非跳过提升
它不是优化，而是不可绕过的语言契约
你无法关闭或规避这个提升——哪怕两个常量byte a = 10, b = 20; byte c = a + b;也会编译失败。因为：
- 编译器必须遵守JLS（Java语言规范）第5.6.2节定义的二元数值提升规则
- 该规则明确要求：若无long/float/double参与，所有整型操作数一律升为int
- 这是保障跨平台一致性的基石：不管在哪台机器上编译，
short + char永远得到int类型结果
