C# string和StringBuilder有什么不同 - 详解字符串拼接的性能陷阱

来源：这里教程网时间：2026-02-21 17:35:06 作者：

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
的线程安全替代方案）