最佳实践是创建时预估初始容量避免扩容：模板拼接加总后×1.1～1.2；集合处理累加后+64～128并取2的幂；循环拼接按均长×n再加10%～20%余量；不可知场景设256/512/1024。
核心就一条：在创建时传入足够但不过量的初始容量，让底层数组一次到位，全程不扩容。
怎么估算才靠谱
不是算得越精确越好，而是覆盖绝大多数实际长度，并留出弹性余量：
- 模板拼接（如
"id={}&name={}"）：把固定部分长度 + 所有变量最大可能长度加总，再乘以 1.1～1.2（例如 ID 最多 20 位、name 最多 50 字符，分隔符和括号共约 12 字，总长预估 ≈ 20 + 50 + 12 = 82 → 设new StringBuilder(96)） - 集合批量处理（如 List 转 CSV）：遍历一次累加所有元素的
length()，再加 64～128（含逗号、换行等），最后向上取整到最近的 2 的幂（如总和 1980 → 用 2048） - 循环拼接 N 条记录：按平均单条长度 × N，再加 10%～20% 波动余量（例如 1000 条 × 35 字符 = 35000 → 设
new StringBuilder(42000)） - 完全不可知但有经验上限：至少设 256 或 512；若常拼日志或 JSON，设 1024 更稳妥
哪些操作要避开
看似省事，实则埋雷：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 别在 for 循环里每次
new StringBuilder()——默认 16 容量，每轮都初始化+可能扩容，开销翻倍 - 别设初始容量为 10000 却只拼 200 字符——浪费堆内存，小对象频繁分配反而加重 GC
- 别依赖
ensureCapacity()替代构造时预估——它只能补救，不能避免首次扩容；且在循环中反复调用没意义 - 别把 StringBuilder 声明为 static 或长期缓存——底层数组会持续膨胀无法回收，变成内存泄漏隐患
复用比新建更高效
尤其在高频或循环场景下：
- 在方法开始处创建一次，全程
append()，最后toString()——这是最常见也最有效的模式 - 需多次构建不同字符串时，用
sb.setLength(0)清空逻辑长度，不释放数组，下次append()直接覆盖，比new快得多 - 避免在循环中频繁调用
toString()获取中间结果——每次都会生成新 String 对象，抵消 StringBuilder 优势
容量和长度别混淆
理解这两个值，才能判断是否真需要扩容：
-
length()是当前已写入的字符数（比如拼了 "abc" 就是 3） -
capacity()是底层数组总长度（new StringBuilder()默认是 16；new StringBuilder("abc")是 19） - 扩容触发条件是：
length() + 新增字符数 > capacity()，不是看 length 是否超了某个阈值 - 扩容公式是
old × 2 + 2（JDK 17+ 改为old + (old >> 1)，即 1.5 倍），但最终会确保 ≥ 所需最小容量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
