StringBuilder适合频繁修改字符串的场景，因其可变性避免了String不可变导致的频繁GC和内存浪费，适用于循环拼接、模板组装、文本解析等动态拼接逻辑。
StringBuilder 适合频繁修改字符串的场景
Java 中 String 是不可变的，每次拼接都会生成新对象，大量拼接会触发频繁 GC、内存浪费。而 StringBuilder 是可变字符序列，内部用 char[] 缓存，所有操作都在原数组上进行（扩容除外），适合需要多次追加、插入、删除的逻辑。
典型场景包括：
- 循环内拼接日志或 SQL 片段（如遍历 List 构造 IN 查询）
- 模板化字符串组装（如 HTML 片段、JSON 字段拼接）
- 解析文本时逐步构建中间结果（如 CSV 行解析、协议报文构造）
别在单次拼接里硬套 StringBuilder
编译器对简单字符串字面量拼接做了优化："a" + "b" + "c" 在编译期就合并为 "abc"；而 String a = "a"; a += "b" += "c" 这种变量拼接，JDK 8+ 也会自动转成 StringBuilder 调用——你手动写反而多此一举。
以下写法没必要，且可读性更差：
StringBuilder sb = new StringBuilder();
sb.append("Hello").append(" ").append("World");
String result = sb.toString(); // 不如直接写 "Hello World"
只有当拼接逻辑动态、分支多、或发生在循环/递归中时，才显式用 StringBuilder。
注意 capacity 和扩容开销
StringBuilder 默认初始容量是 16，每次 append 超出当前 char[] 长度时，会执行扩容：新容量 = 旧容量 * 2 + 2。频繁扩容会复制数组，影响性能。
如果你能预估最终长度，建议显式指定容量：
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 拼接 N 个平均长度 L 的字符串 → 初始容量设为
N * L或稍大 - 构造固定格式日志（如
"[time][level] msg"）→ 按最大可能长度估算 - 不确定长度但有上限 → 用
new StringBuilder(1024)比默认 16 更稳妥
避免这样写：
StringBuilder sb = new StringBuilder(); // 容量 16
for (String s : hugeList) {
sb.append(s); // 每次 append 都可能触发 resize，最坏 O(n²)
线程安全？别用 StringBuffer 除非真需要
StringBuffer 是 StringBuilder 的线程安全版本，所有方法都加了 synchronized。但在绝大多数业务代码中，StringBuilder 实例是局部变量、不跨线程共享，加锁纯属浪费。
常见误判点：
- 以为“日志拼接要线程安全” → 日志框架本身已处理并发，你的
StringBuilder是方法内局部变量 - 在 Spring Bean 里把
StringBuilder当成员变量用 → 这才是真危险，但问题根源是设计错误，不是该换StringBuffer
结论：99% 的情况用 StringBuilder，只有明确需多线程共用同一个实例时，才考虑 StringBuffer —— 但这种设计本身通常就该重构。
最容易被忽略的是容量预估和作用域控制：局部变量用 StringBuilder 很安全，但一旦把它塞进缓存、静态字段或跨方法传递，行为就完全变了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
