StringBuilder适合大量字符串拼接场景，因其不加锁、扩容可控、对象复用率高；应预估容量初始化，避免频繁扩容，仅在最终需要时调用toString()，多线程共享需手动同步。
StringBuilder 适合拼接大量字符串的场景
当需要在循环中反复追加字符串、构建动态 SQL、生成 HTML 片段或组装日志内容时，StringBuilder 比 String 或 StringBuffer 更合适——它不加锁、扩容可控、对象复用率高。
典型错误是用 + 拼接循环体内的字符串，比如：
String result = "";
for (String s : list) {
result += s; // 每次都新建 String 对象，O(n²) 时间复杂度
}换成 StringBuilder 后性能提升明显：
StringBuilder sb = new StringBuilder();
for (String s : list) {
sb.append(s); // 复用内部 char[]，平均 O(1) 摊还成本
}
String result = sb.toString();- 初始化时建议预估容量，避免多次扩容：
new StringBuilder(1024) - 如果拼接逻辑跨多个方法且需线程安全，才考虑
StringBuffer -
StringBuilder不是线程安全的，多线程共享同一个实例必须手动同步
append() 是核心操作，但要注意参数类型和 null 处理
append() 有 13 个重载版本，覆盖 int、char、boolean、Object 等几乎所有常用类型。它对 null 的处理是固定写入字符串 "null"，不是抛异常。
常见陷阱：
- 传入
null的String引用，结果会变成字面量"null"，而非空字符串 - 误用
append(char[])而非append(String)，导致把数组对象地址转成字符串（实际调用toString()） - 连续调用
append().append().append()是安全的
，因为返回
this
示例：
StringBuilder sb = new StringBuilder();
sb.append(null).append("a"); // 结果是 "nulla"
sb.append(new char[]{'x', 'y'}); // 错！结果是类似 "[C@1b6d3586"
sb.append(new String(new char[]{'x', 'y'})); // 对，结果是 "nullaxy"toString() 触发字符串创建，之后修改不影响已生成的 String
toString() 并非廉价操作：它会复制当前内部 char[] 创建新 String 对象。如果频繁调用，可能抵消掉 StringBuilder 的性能优势。
使用注意点：
- 只在最终需要不可变字符串时调用一次
toString() - 不要在循环里反复调用
toString()获取中间结果 -
StringBuilder内部数组不会被String引用，所以后续修改StringBuilder不会影响已生成的String
反模式：
for (int i = 0; i < 100; i++) {
sb.append(i);
String s = sb.toString(); // 每次都复制整个数组，浪费 CPU 和内存
process(s);
}扩容机制影响性能，capacity() 和 length() 容易混淆
length() 返回当前字符数，capacity() 返回内部数组长度。当 length() > capacity() 时，会触发扩容：默认新容量为 oldCapacity * 2 + 2，然后复制数组。
关键事实：
- 初始容量是 16，空构造器不等于“零开销”
- 扩容是自动的，但频繁扩容会引发多次数组复制
- 调用
setLength(0)可清空内容但保留容量，比新建对象更轻量 -
trimToSize()可收缩内部数组到当前length()，节省内存但可能引发下次 append 时立即扩容
推荐做法：
StringBuilder sb = new StringBuilder(2048); // 预分配足够空间 // ... 大量 append ... sb.setLength(0); // 复用同一实例，避免 GC 压力
字符串拼接本身简单，但高频、长生命周期、多线程混用时，StringBuilder 的容量管理、null 边界、线程可见性这些细节，才是实际出问题的地方。
