字符串拼接需按场景选择：小量用+，循环用StringBuilder，线程安全选StringBuffer，复杂模板用MessageFormat/String.format/STR.（Java 21+）；+在编译期常量折叠，含变量时转为StringBuilder但循环中会重复创建对象导致性能下降。
Java 中字符串拼接不是“选一个最快就行”，而是得看场景：小量拼接用 + 最自然；循环内拼接必须用 StringBuilder；涉及线程安全才考虑 StringBuffer；构建复杂模板优先用 MessageFormat 或现代方案如 String.format() 或文本块 + STR.（Java 21+）。
为什么 + 在编译期能优化，运行期却变慢？
Java 编译器对字面量拼接会做常量折叠，比如 "a" + "b" + "c" 直接编译成 "abc"；但一旦含变量（如 "a" + str + "c"），JDK 8+ 默认在底层插入 StringBuilder 调用——看似简单，但如果写在循环里，每次迭代都新建 StringBuilder 对象，就白白浪费堆内存和 GC 压力。
- ✅ 安全场景：
String s = "Hello" + name + "!";（单次、含变量）→ 编译后等效于new StringBuilder().append("Hello").append(name).append("!").toString() - ❌ 危险场景：
String result = ""; for (String item : list) { result += item; // 每次都 new StringBuilder → O(n²) 时间 & 大量临时对象 } - ⚠️ 注意：
final变量也可能被编译器当作常量优化，但别依赖这个行为做性能判断
StringBuilder 和 StringBuffer 到底差在哪？
二者 API 几乎一致，核心区别只有线程安全性：StringBuffer 所有 public 方法都加了 synchronized，而 StringBuilder 没有。绝大多数业务代码是单线程或局部可变对象，用 StringBuilder 就够了，性能高 10%–15%。
- ✅ 推荐写法：
StringBuilder sb = new StringBuilder(); for (String item : list) { sb.append(item).append(","); } String result = sb.toString(); - ✅ 预估容量更高效：如果知道最终长度（比如 list 有 1000 个平均 10 字符的字符串），构造时传入容量：
new StringBuilder(1000 * 11)，避免内部数组多次扩容 - ❌ 不要这样写：
StringBuffer sb = new StringBuffer();然后只在单线程里用——白付同步开销
Java 21+ 的字符串模板（STR.）怎么用？
Java 21 引入预览特性 String Templates（需启用 --enable-preview），本质是编译器支持的“安全插值”，比 String.format() 更灵活，又比手动拼接更可读。
立即学习“Java免费学习笔记（深入）”；
- ✅ 基本用法：
String name = "Alice"; int age = 30; String s = STR."Hello \{name}, you are \{age} years old."; // 输出：Hello Alice, you are 30 years old. - ✅ 支持表达式：
STR."Sum: \{x + y}"、STR."\{list.size() > 0 ? "has items" : "empty"}" - ⚠️ 当前限制：模板处理器（如
STR）默认不做转义或 SQL 参数化，不能直接防注入；若需安全输出 HTML/SQL，仍需额外处理 - ⚠️ 不是语法糖替代品：它不解决循环拼接问题，也不替代
StringBuilder的流式构建能力
真正容易被忽略的是：拼接方式的选择，本质是权衡「可读性」「可控性」和「生命周期」。写日志拼接用 + 没问题，拼千条记录进 CSV 就必须用 StringBuilder 配合预分配；而团队升级到 Java 21 后，别急着全切 STR.，先确认构建工具和 CI 是否已启用 preview 特性——否则编译直接失败。
