编译期常量拼接时+极快，无需替换；运行期循环拼接时+性能差（O(n²)），必须用StringBuilder；少量变量拼接（2~4个）+可读性好且编译器自动优化，性能无差异；单线程优先用StringBuilder，多线程共享修改才考虑StringBuffer。
Java 中用 + 拼接字符串和用 StringBuilder 手动拼接，性能差异明显，但具体差多少、什么时候该换、为什么会有差别，得看场景。
编译期常量拼接：+ 也很快，不需改
如果所有参与 + 的都是字面量或 final 常量（如 "a" + "b" + "c" 或 final String s = "x"; ... s + "y"），JVM 在编译时就合并成一个字符串，生成的字节码里根本没拼接逻辑，和写一个长字符串一样高效。这种情况下，用 + 更简洁，没必要强行改成 StringBuilder。
运行期循环拼接：+ 会严重拖慢，必须用 StringBuilder
在循环中反复用 + 拼接（比如逐行读文件后合并），每次 + 都会创建新的 String 对象，底层实际调用了 StringBuilder 再 toString()，但每次都新建对象、复制旧内容，时间复杂度接近 O(n²)，内存压力也大。
正确做法是：提前声明一个 StringBuilder，循环内只调用 append()，最后统一 toString()：
- 避免重复创建中间字符串对象
- 内部数组可扩容，复制次数远少于
+的隐式调用 - 若预估最终长度，可用
new StringBuilder(estimatedSize)减少扩容开销
少量变量拼接（2~4个）：+ 可读性好，性能差距可忽略
比如 String msg = "User " + name + " logged in at " + time;，JDK 1.5+ 编译器会自动优化为等效的 StringBuilder 调用，生成的字节码几乎一样。此时选 + 更直观、维护成本低，不必为了微乎其微的开销去重构。
注意 StringBuffer 和 StringBuilder 的区别
两者 API 几乎一致，但 StringBuffer 是线程安全的（方法加了 synchronized），而 StringBuilder 不是。大多数场景（单线程、局部变量）应优先用 StringBuilder，它更快；只有明确需要多线程共享并并发修改时，才考虑 StringBuffer，但这种情况本身已属反模式，通常应通过设计规避。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
