java中+=会自动插入窄化转换，而a = a + b不会；因二元运算总提升至int，复合赋值则按jls等价于e1 = (t)((e1) op (e2))，强制截断但不报错。
Java中+=会自动做窄化转换，a = a + b不会
这是最常踩坑的地方：明明两个short相加，用+=能编译通过，换成a = a + b就报错incompatible types: possible lossy conversion from int to short。
原因在于Java的二元算术运算（+、-等）**总会把操作数提升到至少int**。所以short a = 1; short b = 2; a = a + b;实际是int + int → int，再试图赋给short——编译器拒绝隐式窄化。
而+=是复合赋值运算符，语言规范明确要求它在赋值前**自动插入类型转换**，等价于a = (short)(a + b)。
- 只对基本数值类型生效（
byte、short、char参与时最明显） -
String的+=是特例，不涉及数值转换，走的是字符串拼接逻辑 - 自定义类型无法重载
+=，只有+能被重载（如StringBuilder）
复合赋值的类型转换规则不是“取左操作数类型”，而是“按JLS严格定义”
别想当然认为byte += int就是“把右边转成byte”。JLS规定：复合赋值E1 op= E2等价于E1 = (T)((E1) op (E2))，其中T是E1的原始声明类型。
立即学习“Java免费学习笔记（深入）”；
这意味着转换发生在整个表达式求值之后，且强制截断——可能丢数据，但编译器不拦。
-
byte b = 127; b += 1;→ 结果是-128（溢出，但合法） -
char c = 'a'; c += 1000;→ 不报错，结果是'k'（'a' + 1000模65536后截断） -
int i = 0; i += 3.14;→ 编译失败！因为3.14是double，int += double不满足“右操作数可转为左类型的运算结果类型”
泛型和自动装箱场景下，+=的行为更隐蔽
当变量是包装类型（如Integer）时，+=会触发拆箱→计算→装箱三步，且中间的数值运算仍遵守基本类型规则。
比如Integer i = 1000; i += 1;看似简单，实际执行：i.intValue() + 1 → int，再装箱回Integer。这里没类型转换问题，但有缓存陷阱：
- 值在
[-128, 127]范围内的Integer会被缓存，+=后可能复用旧对象 - 超出范围则每次生成新对象，
==比较会意外失败 -
Long l = 1L; l += 1;没问题；但l += 1.0;直接编译错误——不能把double加到Long
性能和可读性上，+=并不总比a = a + b好
字节码层面，两者在基础类型上几乎一样（都是一次加载、一次运算、一次存储）。但可读性和维护性差异明显：
- 对
volatile字段，a += b不是原子操作——它等价于读+算+写三步，和a = a + b一样存在竞态 - 用
+=掩盖类型转换，会让代码意图模糊。比如short s = 0; s += someMethod();，你得去查someMethod()返回什么类型才能确认是否安全 - IDE常把
a = a + b自动优化成a += b，但若原意是强调类型提升（比如故意要int结果），这种替换反而引入bug
类型转换的静默发生，是+=最危险的特质——它让编译器替你做了决定，而这个决定有时连你自己都没意识到。
