编译期常量拼接零临时对象，含变量拼接每次生成至少1个StringBuilder和1个String，循环中+=导致O(n²)复杂度及大量临时对象。
字符串拼接用 + 会生成多少临时对象？
Java 中用 + 拼接字符串，编译器会自动转成 StringBuilder（JDK 5+），但仅限于**编译期可确定的字符串常量表达式**。一旦涉及变量、循环或方法调用，就容易在运行时反复创建新 StringBuilder 实例，导致额外对象开销。
- 静态拼接：
"a" + "b" + "c"→ 编译期直接优化为"abc"，零对象 - 含变量拼接：
"prefix" + str + 123→ 每次执行都 new 一个StringBuilder，再toString()，产生至少 1 个新String对象 - 循环内写
result += s→ 每轮都新建StringBuilder+String，时间复杂度 O(n²)
String.concat() 和 + 的行为差异在哪？
String.concat() 是纯函数式操作：只接受一个 String 参数，内部用 Arrays.copyOf 拷贝字节数组，不复用缓冲区。它比 + 更“老实”，但也更“死板”——不支持多参数、不处理 null、不自动装箱。
- 遇到
null直接抛NullPointerException，而+会转成字符串"null" -
"a".concat("b").concat("c")看似链式，实则每步都生成新String，无缓冲复用 - 参数必须是
String类型，"a".concat(123)编译失败，得先String.valueOf(123)
什么时候必须用 StringBuilder？
三种典型场景下，StringBuilder 不是“推荐”，而是“绕不开”：
- 循环拼接（尤其是
for或while中累积字符串） - 需要复用同一缓冲区多次构建不同结果（比如模板填充、日志组装）
- 已知最终长度，可提前用
new StringBuilder(capacity)避免数组扩容（例如拼接 100 个固定长字符串，预估总长后设初始容量）
示例：
StringBuilder sb = new StringBuilder(512); // 预分配避免扩容
for (String s : list) {
sb.append(s).append(",");
}
String result = sb.toString(); // 只在最后调用一次 toString()
性能差距到底有多大？
在 10k 次拼接测试中（每个片段平均 20 字符）：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
+=循环：约 8–12ms（JDK 17，HotSpot），且 GC 压力明显 -
StringBuilder复用：稳定在 0.3–0.5ms -
String.concat()链式调用：约 4–6ms（每次都要拷贝数组）
差距主要来自内存分配频次和数组复制次数。不过，如果只是偶尔拼两三个字符串（如日志里加个 ID），+ 完全够用，过度优化反而让代码变重。
真正容易被忽略的是：局部 StringBuilder 实例虽然快，但如果在高并发方法里频繁 new，也会触发 minor GC；更稳妥的做法是方法内声明、用完即弃，别试图缓存或复用跨调用的实例。
