string的replace是查找并生成新字符串的不可变操作，每次调用都创建新对象；stringbuilder本质是构建可变文本，适合多次追加、插入等原地修改，不适用于语义替换场景。
String 的 replace 方法和 StringBuilder 本质解决的是不同问题：前者是“查找并生成新字符串”，后者是“构建可变文本”。它们不是直接替代关系，但常被误用于同类场景（比如反复替换或拼接），这时性能差距就非常明显。
replace 是一次性不可变操作
String.replace(CharSequence target, CharSequence replacement) 会扫描整个字符串，找出所有匹配项，然后创建一个全新字符串返回。原字符串不变，每次调用都产生新对象。
- 底层基于
String.indexOf+ 数组拷贝，适合单次、低频替换 - 不涉及扩容、不维护状态，调用开销小，但结果必然分配新 char[]
- 例如：
"a-b-c".replace("-", "_")→ 返回新字符串"a_b_c"，原串仍为"a-b-c"
StringBuilder 不提供 replace，但能高效实现“多次修改”
StringBuilder 本身没有 replace 方法（它有 replace(int start, int end, String str)，但那是按索引区间替换，非语义匹配）。它真正优势在于：当你要做“多次追加、插入、删除、局部覆盖”时，全程复用同一块内存。
- 比如循环中不断拼接 + 条件性修改：
sb.append("key=").append(val).append("&")，全程无新对象 - 若硬要用 StringBuilder 模拟
replace（如先indexOf再delete+insert），反而比 String.replace 更慢——因为破坏了它的设计初衷 - 真正该用 StringBuilder 的场景，是“组装”，不是“查找替换”
性能对比的关键分水岭
差异不在单次调用快慢，而在是否重复执行：
- 单次替换（如日志模板填空）：
str.replace("{id}", id)简洁安全，性能足够 - 循环内多次替换（如解析每行 CSV 并清理字段）：
for (line : lines) { line.replace(...); }→ 每次都新建字符串，GC 压力陡增 - 此时应换思路：用 StringBuilder 构建新内容，而非反复替换旧内容。例如逐字段处理后
sb.append(cleanedField).append(",")
别混淆 replace 和拼接逻辑
常见误区是把 str += "a" + i 当作“替换”，其实这是拼接；而 str.replace("old", "new") 才是语义替换。编译器对 += 的优化（转成 StringBuilder）仅适用于纯拼接链，不适用于含 replace 的表达式。
- ❌ 错误优化：
result = ""; for(...) result = result.replace("x", "y") + data;→ 每轮都 new String + new StringBuilder（隐式） - ✅ 正确做法：先用 StringBuilder 组装原始数据，再统一用 String.replace 处理最终结果（如去空格、标准化）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
