用对 StringBuilder 的关键是预估容量、只用 append()、及时 toString()。默认容量 16，扩容耗性能；应预设容量如 new StringBuilder(3200)；禁用 += 和 +；避免循环内 toString()；null 需显式处理；静态拼接用 + 更优。
用对 StringBuilder，关键不在“用了没”，而在“怎么用”。它不是拼接工具的万能解，而是需要配合场景、容量预估和调用习惯才能发挥价值的可变容器。
预设容量比默认构造更稳
StringBuilder 默认初始容量是 16，超出就扩容（通常是 oldCapacity × 2 + 2），每次扩容都要复制整个底层数组——这是隐藏性能开销的主因。
- 能预估最终长度时，直接指定容量：比如拼接 200 个平均 15 字符的字符串加逗号分隔，总长 ≈ 200×15 + 199 ≈ 3200，可写 new StringBuilder(3200)
- 不确定但数据量大，宁可略高估（多留 10–20 字符余量），也别频繁扩容
- 避免用 ensureCapacity() 补救——它只扩不缩，还多一次方法调用
所有拼接必须走 append()，禁用 += 和 +
StringBuilder 的价值在于复用内部数组。一旦混用 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() 或 Collectors.joining() 更安全简洁
- 需要跨线程共享拼接结果？别共享 StringBuilder 实例，拼完再发布不可变 String
