绝大多数场景优先用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()的包装，唯一优势是支持链式调用、延迟执行（配合函数式接口），但无性能增益 - 二者都不改变原字符串，也不涉及
S，纯属
tringBuilderString实例方法增强；若项目还停留在 Java 11 或更低，它们根本不可用
tringBuilder真正需要关注的是 String 的底层存储变化：Java 9 开始用 byte[] + coder 字段节省内存（Latin-1 编码下空间减半），但这对开发者透明，只影响 GC 压力和堆占用。
