应按最终字符串长度预估StringBuilder初始容量，而非凭经验设固定值；需累加固定模板、变量最大长度、结构符号，并留10%～20%余量；优先用带参构造器，ensureCapacity仅作兜底；过大容量会浪费内存。
初始化 StringBuilder 的初始容量，核心是**按最终字符串长度预估，而不是凭经验填个固定数字**。默认的 16 容量在大文本场景下几乎必然触发多次扩容，每次扩容都要分配新数组 + 复制旧内容，开销是线性的，数据量越大越明显。
怎么算出合理的 initialCapacity
关键不是“猜”，而是把所有能确定或可估计的字符来源加总：
- 固定模板部分：比如
"INSERT INTO users (id, name, created) VALUES "这段字面量长度是 42，直接计入 - 变量部分：按最大可能长度算——
int最多 11 位（含负号），long最多 20 位，用户名 ≤25 字符，时间戳 ISO 格式固定 29 字符 - 结构符号：每个值之间逗号+空格共 2 字符，n 条记录就有 n−1 个；括号、分号、换行符等也一并累加
- 留 10%～20% 余量：应对估算偏差，但别翻倍预留（如预估 8000 却设 16000）
常见场景的估算方式
不同拼接模式有对应策略，避免一刀切：
- 固定格式日志/SQL 批量拼接：先统计字段数 × 平均长度 + 分隔符总数，再向上取整到 2 的幂（如 3980 → 4096，7250 → 8192）
- JSON 或 URL 参数构建：把引号、冒号、逗号、等号、& 符都当作固定开销，和 value 长度分别计算后相加
-
流式读取但有单行上限：比如协议规定单行最长 65535 字节，那就直接设
new StringBuilder(65535)，比依赖自动扩容稳定得多
什么时候该用 ensureCapacity 而不是构造器参数
不是所有情况都能在创建时就拿到总长。这时可在拼接前统一补调一次：
立即学习“Java免费学习笔记（深入）”；
- 已知片段集合（如
List<String>），先遍历求和所有str.length()，再加结构开销，最后调sb.ensureCapacity(total + 200) - 避免在循环体内反复调用 —— 它只在不足时生效，但频繁判断本身有开销
- 构造时能预估，就优先用带参构造器；
ensureCapacity是兜底手段，不是替代方案
容量设太大也不行
过大的 initialCapacity 会浪费堆内存，尤其在高并发短任务中：
- 检查
sb.capacity() - sb.length()：差值长期是 length 的几倍，说明预留严重过剩 - 对平均长度 50 的日志行，设 4096 容量就过度了；设 128 或 256 更平衡
- 没把握时，宁可从 4096 或 8192 起步，也别用默认 16
