string拼接用+在循环中性能差，因每次生成新对象并复制内容，时间复杂度达o(n²)，且编译器无法复用stringbuilder，日志中还存在隐式执行开销。
因为string在java中是不可变的，每次用+拼接，都会生成一个全新的string对象，原字符串内容被完整复制过去再追加新内容。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
不可变性导致每次拼接都新建对象
String底层封装了一个char[]数组，且该数组一旦初始化就不可修改。所以s = s + "a"并不是在原地添加字符，而是：
• 创建一个新的、更大的char[]数组
• 把原字符串的字符逐个拷贝进去
• 再把新内容追加到末尾
• 最后用这个新数组构造一个全新的String实例
这意味着每执行一次+，就产生一个临时String对象，旧对象留在堆中等待GC回收。
循环中问题被急剧放大
在for循环里反复使用+=，等价于连续做n次独立拼接：
• 第1次：生成长度L₁的对象
• 第2次：拷贝L₁内容 + 新字符串 → 生成L₂对象
• 第3次：拷贝L₂内容 + 新字符串 → 生成L₃对象
……
累计复制的数据量接近O(n²)，内存分配次数和GC压力直线上升。即使编译器对单行多变量拼接做了StringBuilder优化，它也**无法智能识别循环结构并复用同一个StringBuilder**，往往仍会在每次迭代中新建实例。
默认容量小，扩容进一步加重开销
如果编译器确实生成了new StringBuilder()，其默认初始容量只有16。当拼接内容超过这个长度，就会触发扩容：
• 创建新数组（通常是oldCapacity * 2 + 2）
• 将旧数组全部复制过去
• 继续append
循环中频繁扩容+复制，比单纯新建对象更耗时。而开发者无法控制编译器生成的StringBuilder是否预设容量。
日志等场景还存在隐式执行风险
像log.debug("id=" + user.getId() + ", name=" + user.getName())这类写法：
• 即使日志级别为INFO（debug不输出），字符串拼接仍会执行
• 所有+操作照常创建临时对象、调用getter方法
• 白白消耗CPU和内存
这属于“无意义的隐式拼接”，表面看只是语法糖，实际运行时开销显著。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
