绝大多数场景优先用StringBuilder；线程安全时选StringBuffer；常量拼接由编译器自动优化。关键在“谁在改”和“谁可能同时改”：String不可变，StringBuilder可变非线程安全，StringBuffer线程安全但有锁开销。

String、StringBuilder、StringBuffer 三者怎么选

绝大多数场景下，优先用 StringBuilder；需要线程安全时才考虑 StringBuffer；纯拼接常量或简单表达式，编译器会自动优化成 StringBuilder，不用手动干预。

关键区别不在“能不能改”，而在“谁在改”和“谁可能同时改”：

• String 不可变，每次 + 或 substring() 都新建对象，高频拼接或循环中反复操作会触发大量 GC
• StringBuilder 可变、非线程安全，单线程下性能最优，内部用 char[]（Java 9+ 是 byte[] + 编码标记）动态扩容
• StringBuffer 方法全加了 synchronized，多线程安全但锁开销明显，除非明确在共享可变字符串对象且无法重构为无状态，否则不推荐

StringBuilder 常见误用与扩容陷阱

默认构造函数创建的 StringBuilder 初始容量是 16，一旦追加内容超过该长度，就会触发数组扩容——本质是新建更大数组、复制旧内容。高频小拼接（如日志组装、SQL 拼接）若没预估长度，可能反复扩容拖慢性能。

实操建议：

• 知道大致长度时，直接指定初始容量：new StringBuilder(256)
• 拼接已知字符串数组，用 String.join() 更简洁（Java 8+），它内部也用 StringBuilder，但做了容量预计算
• 避免在循环内反复创建 StringBuilder：把实例提到循环外复用，尤其在方法内部被多次调用时
• 不要用 toString().length() 判断是否为空，用 length() == 0，前者多一次对象创建

Apache Commons Lang 的 StringUtils 能省多少事

原生 String API 对空值处理极其脆弱：str.trim() 在 str == null 时直接抛 NullPointerException。而 StringUtils 几乎所有方法都做了 null 安全封装，且语义更贴近日常需求。

典型替代场景：

• 判空：StringUtils.isEmpty(str) 等价于 str == null || str.length() == 0，比 Objects.isNull(str) || str.isEmpty() 少写一半
• 去前后空格并判空：StringUtils.isBlank(str) 还会检查空白字符（如 "\t\n "）
• 安全截断：StringUtils.substring(str, 0, 10) 在 str == null 或越界时不报错，返回 null 或原串
• 集合转字符串：StringUtils.join(list, ", ") 自动跳过 null 元素，无需提前过滤

注意：它不替代 StringBuilder，而是补足原生 API 的健壮性缺口。引入 commons-lang3 依赖后，这些方法基本零学习成本。

Java 12+ 的 String.indent() 和 transform() 值不值得用

这两个方法属于“写起来爽、读起来清”的语法糖，但需留意兼容性和实际效果：

• str.indent(4) 在每行前加 4 个空格，但会移除原字符串首尾空白行，且对首行缩进逻辑特殊（不缩进首行换行符后的部分）——容易和预期不符，调试时建议先打印结果
• str.transform(s -> s.toUpperCase()) 本质就是 s.toUpperCase().toString() 的包装，唯一优势是支持链式调用、延迟执行（配合函数式接口），但无性能增益
• 二者都不改变原字符串，也不涉及 StringBuilder，纯属 String 实例方法增强；若项目还停留在 Java 11 或更低，它们根本不可用

真正需要关注的是 String 的底层存储变化：Java 9 开始用 byte[] + coder 字段节省内存（Latin-1 编码下空间减半），但这对开发者透明，只影响 GC 压力和堆占用。