字符串长度是合理的初始容量，因为stringbuilder内部用char数组存储，按最终长度初始化可避免扩容开销；需预留余量的场景包括频繁insert/replace、变量转字符串长度不确定、含固定分隔符的拼接；不宜过度估算或硬编码大容量。
直接用字符串长度作为 StringBuilder 的初始容量，通常就足够了。
为什么字符串长度是合理的初始容量
StringBuilder 内部用 char 数组存储内容，扩容会触发数组复制，带来额外开销。如果预先知道最终字符串长度（比如拼接固定内容、格式化已知字段），按该长度初始化容量，就能避免扩容。
例如：new StringBuilder(str.length()) 适合用于后续只追加内容且总长可预估的场景；若还要插入或删除，可略留余量。
需要额外预留空间的常见情况
以下情况建议在原始长度基础上增加少量缓冲：
- 拼接过程中会多次调用 insert() 或 replace() —— 插入位置靠前时可能触发数组移动，预留 10~20% 更稳妥
- 使用 append() 拼接多个字符串，但部分参数本身是变量（如数字、布尔值）—— toString() 转换后长度不确定，可按最大可能长度估算（如 int 最多 11 位，long 最多 20 位）
- 构建 JSON 或 URL 等含固定分隔符的字符串（如 "key=" + value + "&"）—— 把已知符号长度（等号、&、引号等）一并计入
不建议过度估算或硬编码大容量
设过大容量（如 1024、8192）看似“保险”，但会浪费内存，尤其在高并发或大量短字符串场景下。JVM 堆中碎片增多，GC 压力上升。
也不建议用经验值代替计算：比如一律用 64 或 128，对长度为 5 的字符串来说冗余严重；对长度为 500 的字符串又可能触发扩容。
动态拼接时的实用策略
如果最终长度无法精确预估，但有大致范围，可用以下方式平衡性能与简洁性：
- 先用 String.join() 或 MessageFormat 替代手工拼接（它们内部已优化容量）
- 若必须用 StringBuilder，可先累加所有片段长度（str1.length() + str2.length() + ...），再加 10~16 字节余量
- 对日志类拼接，优先考虑 String.format() 或 SLF4J 的占位符（如 log.debug("user={}, action={}", user, action)），它们延迟格式化，不创建中间 StringBuilder
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
