string 拼接慢因每次操作都创建新对象并复制内存，导致 O(N²)开销和 GC 压力；StringBuilder 通过可扩容数组避免频繁分配，适合多次修改场景。1. 初始化应预设容量减少扩容；2. 仅在循环或条件拼接时使用；3. 拼接少于 3～4 次或用插值时不需替换；4. 非线程安全，高并发需加锁；5. 单次拼接由编译器优化为 Concat 更高效。正确使用下 StringBuilder 性能远超 string，但需权衡场景。
string 是不可变的，StringBuilder 是可变的 —— 这是性能差异的根本原因。每次用 + 或 += 拼接 string，都会创建一个新对象；而 StringBuilder 在内部维护一个可扩容的字符数组，反复追加不频繁分配内存。
为什么 string 拼接会变慢？
因为 .NET 中 string 类型被设计为 不可变（immutable）：任何修改操作（包括拼接、替换、截取）都会生成全新字符串对象，原字符串不变。例如：
-
string s = "a"; s += "b"; s += "c";实际创建了 3 个字符串对象（”a”、”ab”、”abc”） - 循环中拼接 N 次，会产生 O(N²) 级别的内存复制（每次都要把之前所有字符再拷贝一遍）
- 大量短生命周期字符串会加重 GC 压力，尤其在高频或服务端场景下明 显卡 顿
StringBuilder 真的更快吗？怎么用才对？
它快，但不是“无脑换就完事”。关键看使用方式：
- 初始化时尽量指定容量：
new StringBuilder(1024)，避免多次自动扩容（默认初始容量 16，翻倍增长） - 只在需要多次修改时用，比如循环拼接、条件分支拼接、日志组装等
- 用完记得调用
.ToString()获取最终结果；不要反复调用它来获取中间值（没意义还多一次拷贝） - 单次拼接（如
"Hello " + name + "!"）编译器会自动优化成string.Concat，比 StringBuilder 更轻量
哪些情况不用 StringBuilder？
盲目替换反而画蛇添足：
- 拼接次数 ≤ 3～4 次的静态字符串（编译期常量合并很高效）
- 使用
$"……"插值且变量少、无循环（C# 10+ 对简单插值做了内联优化） - 拼接后立即丢弃、不复用 StringBuilder 实例（对象创建 + 销毁开销可能抵消收益）
- 高并发写同一 StringBuilder（它不是线程安全的，需手动加锁或改用
System.Text.StringBuilder的线程安全替代方案）
一个直观对比示例
拼接 10000 次 “x”：
-
string方式：约 300ms+，内存分配飙升，GC 明显抖动 -
StringBuilder（预设容量）：约 0.2ms，几乎无额外分配 -
string.Concat/string.Join批量处理：也很快，适合已知集合的场景
基本上就这些。核心就一条：string 适合“读多写少”，StringBuilder 适合“写多读少”——看清场景，别让优化变成负担。
