关键在于正确使用细节：预设容量避免扩容开销，坚持append()链式调用禁用+操作，明确null处理与toString()时机，区分适用场景，非必要不替代String.join等优化方法。
用对 StringBuilder 的关键，不在“用了没”，而在“怎么用”。真正影响性能和稳定性的，是几个高频出错的操作细节。
预设容量比默认构造更稳
默认初始容量是 16，一旦超出就会触发扩容（新容量 ≈ 旧容量 × 2 + 1），每次扩容都要复制整个底层数组——这是隐藏开销的主要来源。
- 能预估最终长度时，直接指定容量：比如拼接 200 个平均 15 字符的字符串加逗号分隔，总长 ≈ 200×15 + 199 ≈ 3200，可写 new StringBuilder(3200)
- 不确定但数据量大，宁可略高估（多留 10–20 字符余量），也别频繁扩容
- 避免用 ensureCapacity() 补救——它只扩不缩，还多一次方法调用
所有拼接必须走 append()，禁用 += 和 +
StringBuilder 的价值在于复用内部 char 数组。一旦混用 sb.append("a") + "b" 或 sb.toString() + "c"，就会立刻创建新 String 对象，让前面所有优化失效。
- 坚持链式调用：sb.append("id:").append(id).append(", name:").append(name)
- 不要写 sb.append("a" + "b")——编译器会先生成临时 StringBuilder，白费力气
- 循环内绝对禁止 String s = ""; s += item;，1000 次迭代可能产生上千个中间对象
null 处理和 toString() 时机要明确
append(null) 会转成字符串 "null"，不是空字符串；toString() 是获取结果的必经步骤，不是可选项。
立即学习“Java免费学习笔记（深入）”；
- 业务不允许 null 字面值时，提前判空或用 Objects.toString(x, "")
- 拼接完成后必须调用 toString()，否则拿不到 String 实例
- 避免在循环中反复调用 toString()——每次都会复制整个数组，开销是 O(n)
- 去尾逗号等简单修改，优先用 sb.delete(sb.length()-1, sb.length())，比 substring 更高效
别在错的场景硬套 StringBuilder
它不是万能银弹。编译期就能确定的少量拼接（比如 1–2 次静态字符串连接），用 + 更简洁，JDK 会自动优化为 StringBuilder。
- 适合 StringBuilder 的典型场景：循环拼接、SQL/JSON/HTML 动态生成、日志组装等热路径
- 只是把 List 拼接成逗号分隔串？优先用 String.join(",", list)——它内部已优化，还自动跳过 null 元素
- 单线程下首选 StringBuilder；多线程共享才考虑 StringBuffer
