Java复合赋值运算符隐含窄化类型转换，如short s=1; s+=1;合法而s=s+1;报错；连续赋值a=b=c仅适用于已声明变量且右结合；==比较引用或原始值，对象应使用.equals()；循环中String+=导致O(n²)性能问题。
Java里+=这类复合赋值不是简单缩写
它隐含类型转换，而且会悄悄改变计算顺序。比如short s = 1; s += 1;能编译通过，但s = s + 1;会报错：「possible loss of precision」。因为s + 1结果是int，而+=在赋值前自动做了窄化转换。
- 所有复合赋值运算符（
+=、-=、*=、/=、%=、等）都带这个隐式强制转换行为 - 仅适用于变量在左，且该变量类型比右操作数“更窄”时才体现差异；两边同为
int就看不出区别 - 别用它来“绕过类型检查”——比如
byte b = 127; b += 1;会溢出成-128，这不是bug，是规范定义的行为
连续赋值a = b = c只在声明后有效
Java不支持像C那样在声明时链式初始化，比如int a = b = c = 0;直接编译失败：「cannot find symbol」。因为b和c还没声明，=又不具备声明能力。
- 连续赋值只能用于已声明的变量：
int a, b, c; a = b = c = 42;合法 - 它从右往左结合：
a = b = c等价于a = (b = c)，所以b = c先执行并返回c的值 - 注意副作用：如果
c是方法调用（如getCounter()），它只被调用一次；但若写成a = getCounter(); b = getCounter();，就调两次
==比较引用还是值？这取决于类型
很多人以为==就是“等于”，其实它永远只比较内存地址（引用）或原始值（primitive），从不调用equals()。对象比较时，==几乎总是错的，除非你真要判断是不是同一个对象实例。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 基本类型（
int、char、boolean等）用==没问题 - 包装类（
Integer、String等）用==可能意外成功——比如Integer a = 100; Integer b = 100; a == b为true（缓存导致），但换成1000就变成false - 数组、自定义对象、
new String("x")这类，一律用.equals()，==只反映是否同一块内存
字符串拼接中+=的性能陷阱
在循环里用str += "x"看起来简洁，但每次都会新建String对象，时间复杂度是O(n²)。JVM虽有优化（比如把多个+=合并为StringBuilder），但只在**单条语句内**生效，跨循环就不行。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
String s = ""; for (int i = 0; i - 正确写法：
StringBuilder sb = new StringBuilder(); for (int i = 0; i - 编译器对
"a" + "b" + "c"这种字面量拼接会直接优化成"abc"，但一旦出现变量（哪怕只是"" + x），就退化为StringBuilder逻辑
+=的上下文依赖性——它们看着像语法糖，实则行为边界很具体，一不留神就掉进语义坑里。 
