StringBuilder是单线程大量字符串拼接的首选，因其基于可扩容char[]避免频繁GC；应避免误用StringBuffer、简单拼接或需格式化/正则的场景。
字符串拼接量大且发生在单线程循环内
当需要在 for 循环中拼接几十次甚至上千次字符串（比如构建日志行、生成 CSV 行、组装 SQL 参数），StringBuilder 是首选。它底层用可扩容的 char[]，避免了每次拼接都新建 String 对象带来的 GC 压力。
常见错误是写成这样：
String s = "";
for (int i = 0; i < 1000; i++) {
s += "item" + i; // 每次触发 new String() + System.arraycopy()
}
换成 StringBuilder 后性能通常提升 5–10 倍（取决于 JDK 版本和长度）：
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
sb.append("item").append(i);
}
String result = sb.toString();
- 初始化时尽量预估容量：
new StringBuilder(2048)可减少数组扩容次数 - 避免在循环里反复调用
toString()，它会创建新String对象 - 不要用
StringBuilder替代String存储长期状态——它不是不可变的，线程不安全
需要链式调用或分段构造字符串
StringBuilder.append() 返回自身，天然支持链式写法，适合逻辑分散但目标一致的拼接场景，比如 HTTP 响应体组装、模板填充、JSON 片段生成。
立即学习“Java免费学习笔记（深入）”；
例如构造一个带条件字段的 JSON 片段：
StringBuilder json = new StringBuilder("{");
json.append("\"name\":\"").append(name).append("\"");
if (age > 0) {
json.append(",\"age\":").append(age);
}
if (email != null) {
json.append(",\"email\":\"").append(email).append("\"");
}
json.append("}");
- 比用
+拼接更清晰，尤其分支多时不会产生大量临时String - 注意：
append(null)会写入字符串"null"，不是空指针异常，需提前判空 - 如果拼接逻辑跨多个方法，把
StringBuilder当参数传入比返回拼接结果更高效（避免中间toString()）
替代 StringBuffer 的唯一合理理由：确认单线程
StringBuffer 和 StringBuilder API 几乎完全一致，区别只在 StringBuffer 所有 public 方法加了 synchronized。如果你明确知道拼接操作不会被多线程并发调用（比如 Servlet 的 doGet 内局部变量），就该用 StringBuilder。
实测在 JDK 17 下，单线程场景中 StringBuilder.append() 比 StringBuffer.append() 快 15%–25%，差距随调用频次增大而明显。
- 别为了“以防万一”而默认用
StringBuffer——同步开销白交，且掩盖真实并发问题 - 如果真有多线程共享拼接需求，优先考虑设计上拆分任务，而不是依赖
StringBuffer - JDK 9+ 中
StringConcatFactory已优化常量拼接，但运行时动态拼接仍绕不开StringBuilder
不适合的场景：简单拼接、编译期可确定、或需正则/格式化
以下情况用 StringBuilder 反而是过度设计：
- 两三个字符串拼接：
"Hello " + name + "!"在 JDK 9+ 会被编译器自动优化为StringBuilder，手写反而啰嗦 - 含格式化逻辑：
String.format("User %s, age %d", name, age)更语义清晰，且底层也用了StringBuilder，无需自己封装 - 需要频繁截取、替换、匹配：
StringBuilder没有replaceAll()或matches()，强行用它做文本处理会写得很别扭 - 拼接结果要立刻用于
Mapkey 或switchcase：必须是String，且要求不可变性，此时toString()是必要步骤，但要注意别在关键路径反复创建
真正容易被忽略的是：StringBuilder 的 capacity() 和 length() 不同——length() 是当前字符数，capacity() 是底层数组大小。调试时看到 capacity 远大于 length 不代表内存泄漏，只是预留空间。
