在服务端做数据导出时我踩过一次印象很深的坑用VB.NET循环拼接2万多个编码直接把窗体卡成白屏等了几十秒才弹出结果后来换成StringBuilder耗时从十几秒降到几十毫秒。从那以后每逢看到项目里出现str ...的写法我都会多看一眼。这次专门写一篇VB.NET性能实测对比把StringBuilder和String拼接放在同一台机器、同一组循环里跑数据用Stopwatch说话的适合刚入门VB.NET的人也适合一直凭感觉选拼接方式、想搞清楚到底差多少、为什么差这么多的同学。先说结论字符串是不可变对象每次拼接都会创建一个新字符串并复制旧内容循环拼接的代价会随次数增加而指数式膨胀StringBuilder通过内部缓冲区避免了反复创建新对象所以在大规模拼接场景下优势非常明显。下面我会把测试代码、原始数据、背后原理和几个容易踩的坑一次性讲透。1. String不可变为什么拼接写多了必然变慢1.1 一次String拼接的完整代价拆解大家写Dim s As String 的时候s指向的是一个存在于托管堆上的字符串对象。字符串对象是只读的你没法修改它的内容所有看起来像修改的操作实际都是重新创建了一个全新的字符串对象。所以执行s value时底层做的事情大致分三步先申请一块能装下原字符串长度 新内容长度的新内存把原字符串内容完整复制过去再把要追加的内容复制到尾部最后让变量s指向这个新对象。原来的字符串对象如果没有任何引用指向它就会被垃圾回收器当垃圾回收。问题在于每拼接一次就要把前面所有字符再复制一遍。假设每次追加的平均长度是4个字符拼到第N次时单次操作需要复制的字符数量约等于前N次累积的总长度也就是4 * N个字符。而整个循环下来复制总量是4 * (1 2 3 ... N)最终会达到O(N²)级别的字符复制量。这就是为什么拼1万次已经不流畅、拼10万次能卡到让人怀疑人生的根本原因。1.2 拼接规模增长时的复杂度变化很多人对拼接会变慢没有直观感受是因为拼接几百次时复制总量只有几十万字符现代CPU一眨眼就处理完了。但把规模放大到1万、10万复杂度曲线就很恐怖了。我们看一个简单的推导。假设循环拼接N次每次追加固定长度的内容第i次拼接需要复制的字符数正比于已有字符串的长度也就是正比于i总复制字符数约为常数 * N² / 2字符串对象还伴随着大量的内存分配N越大GC的回收压力也越大StringBuilder则完全不同。它内部维护了一块连续的可变字符缓冲区追加操作是把内容写进缓冲区里的一个空闲位置只要缓冲区容量足够就不发生复制、不产生新的字符串对象。这个设计让平均单次操作复杂度降到接近O(1)整体复杂度接近O(N)。两者从本质上是两种效率级别而不是单纯的快一点。理解这一点后面看数据就不会奇怪了。2. 实测前的准备测试环境、代码与误差控制2.1 测试环境与采样策略性能测试最怕的就是环境不一致。我这次特意把测试代码放在同一个解决方案里编译成Release模式运行避免Debug模式下编译器不优化导致的偏差。具体配置如下。项目配置操作系统Windows 11 Pro x64开发工具Visual Studio 2022运行时.NET Framework 4.8 与 .NET 8 分别验证编译模式Release / AnyCPU / X64计时方式System.Diagnostics.Stopwatch统计口径每组重复5次取中位数我建议你也照这个方式做先用一段简单的代码预热让JIT完成方法编译再正式计时。另外Stopwatch底层用的是高精度计数器比DateTime.Now测耗时可靠得多千万别用后者。受垃圾回收影响字符串拼接这种会大量产生垃圾的操作单次运行结果可能忽高忽低。所以我每组跑5次去掉最高和最低取中间的值。你看到的数据不是一次偶然结果而是多次采样后的稳定值。2.2 测试代码String拼接与StringBuilder对比测试逻辑很简单循环count次分别用普通字符串拼接和StringBuilder追加每次追加一个整数转成的字符串最后统计耗时。下面是String拼接的写法。Dim sw As Stopwatch Stopwatch.StartNew() Dim result As String For i As Integer 0 To count - 1 result i.ToString() Next sw.Stop() Console.WriteLine($String拼接 {count} 次耗时: {sw.Elapsed.TotalMilliseconds:F2} ms)StringBuilder的写法如下。Dim sw As Stopwatch Stopwatch.StartNew() Dim sb As New StringBuilder() For i As Integer 0 To count - 1 sb.Append(i.ToString()) Next Dim result As String sb.ToString() sw.Stop() Console.WriteLine($StringBuilder 拼接 {count} 次耗时: {sw.Elapsed.TotalMilliseconds:F2} ms)这里有个容易忽略的点StringBuilder用例里最后必须调用ToString()否则编译器可能会认为sb的结果从未被使用在某些优化场景下甚至可能把循环优化掉。我让它生成一个最终字符串更贴近真实业务。3. 实测数据不同拼接次数下的性能差异3.1 1000次与10000次量变到质变先看小规模数据。在.NET 8下我的测试结果为拼接次数String拼接耗时StringBuilder耗时差距倍数1,0000.58 ms0.08 ms约7倍10,000182.40 ms0.62 ms约294倍1000次时String拼接不到1毫秒StringBuilder也接近微秒级两者用起来没本质区别。但到了1万次String拼接已经接近200毫秒界面会明显卡顿而StringBuilder还是不到1毫秒。这个阶段已经能测出天壤之别了。为什么1万次会突然变慢按照前面的复杂度推导1万次拼接的累积复制量大约是几千万字符级别也就是几GB的纯内存拷贝和分配量。虽然听起来吓人但在现代硬件上也就是一两百毫秒的量级。到了这个规模GC的频繁回收会让耗时更加不稳定有时候快有时候明显变慢。3.2 10万次与100万次StringBuilder的碾压表现继续放大规模差距会从差异明显变成根本无法对比。拼接次数String拼接耗时StringBuilder耗时差距倍数100,000约 6400 ms4.3 ms约1400倍1,000,000内存占用过大未完成38.6 ms无法统计10万次String拼接耗时要6秒多这在客户端应用里已经是不可接受的体验了而StringBuilder只用了4.3毫秒几乎感知不到。100万次时String拼接已经不只是慢的问题而是会分配出大量待回收的字符串对象内存占用火箭式上升我跑的时候直接把进程内存顶上去了最终被迫终止。这里提醒一句如果你在真实项目里看到某个接口偶发超时而代码里恰好有个循环在拼字符串不要犹豫先把它改成StringBuilder这往往是免费的午饭。3.3 String.Join与编译器优化的补充观测除了StringBuilder还有一个经常被忽略的选项String.Join。如果你要拼接的是一个已知元素集合String.Join在底层会先算出所有元素的总长度一次性分配一块正好合适的空间再逐段复制进去。这样只分配一次某些情况下甚至比StringBuilder循环追加更快。Dim items As New List(Of String)() For i As Integer 0 To count - 1 items.Add(i.ToString()) Next Dim joined As String String.Join(,, items)但要注意String.Join要求你先把数据放进集合里这本身也有开销。如果数据本来就在集合中用Join非常划算如果是一次性流式生成则用StringBuilder更自然。实际项目中两者经常搭配使用。4. StringBuilder为什么快缓冲区机制与配置细节4.1 内部缓冲区的扩容策略StringBuilder的底层是一个Char[]类型的缓冲区外加一个记录当前写入位置的长度字段。每次Append它只做两件事检查缓冲区剩余空间是否够用如果够用就直接把新字符写入如果不够用才触发扩容。扩容时会创建一块更大的缓冲区把原有内容复制过去然后继续写入。默认情况下StringBuilder初始容量只有16个字符扩容策略是成倍增长16变3232变64这样扩下去。如果拼接次数很大反复扩容本身也会产生复制开销只是这个开销被控制在对数级别比String拼接的线性复制加分配温和太多。4.2 Capacity预分配的重要性和操作方式既然瓶颈可能出现在扩容上那最好一开始就把缓冲区设得足够大。你能估算最终字符串的大致长度时直接用带容量的构造器能省掉几乎所有中间扩容。Dim estimatedLength As Integer count * 4 Dim sb As New StringBuilder(estimatedLength)比如前面测试里每个整数平均大概4个字符拼count次后总长度约count * 4预分配这个容量后整个拼接过程几乎不会再触发扩容。实际项目里估算不准也没关系稍微高估一点比低估好只多占一点内存换来的是稳定的性能。也可以动态调整Capacity属性。但注意Capacity小于当前字符串长度时会抛出异常所以缩放容量前要确认不会缩短到实际长度以下。4.3 为什么编译器没有帮String拼接做更多优化有朋友会问编译器能不能像处理常量拼接那样把循环里的拼接也优化掉答案是不能或者说很难。如果拼接的内容是编译期就能确定的常量比如A B C编译器会直接合并成一个字符串文本这时候用普通拼接反而是最优解StringBuilder纯属多余。但循环中的拼接不同每次追加的内容来自变量编译器无法预知所有内容只能老老实实地在运行时创建新字符串。因此不要指望编译器帮你优化动态拼接。理解这条界线你就知道什么场景该用谁了能用常量写死的少数拼接用普通数据量不确定、又在循环里追加的直接上StringBuilder。5. 常见误区、使用边界与避坑建议5.1 哪些场景应该继续用String拼接String拼接也不是一无是处。少量拼接时比如代码里出现Dim fullName As String firstName lastName这种一次性的拼接用普通可读性最好性能也是最优的。这个场景下引入StringBuilder不仅没有收益还会让代码变啰嗦。另一个值得注意的场景是日志消息的拼接。如果你用$...拼接一串日志文本而日志级别关闭时可能会直接跳过参数求值那么这种写法反而是好事。但要警惕的是如果日志框架无论如何都会执行字符串构造该优化才是真的必要。我的经验法则是循环次数少、确定在一百以内时普通拼接完全没问题循环次数有放大可能、或者你已经确认这段代码会被高频调用直接用StringBuilder。矫枉过正地用StringBuilder拼三个固定字符串反而会让代码显得很奇怪。5.2 多线程下的StringBuilder风险StringBuilder不是线程安全的。多个线程同时往同一个StringBuilder实例里Append轻则内容顺序错乱重则触发缓冲区异常。如果你在多线程环境里需要拼接让每个线程持有自己的StringBuilder实例最后再合并结果。合并时也注意用多次Append把每段内容带入同一个总拼接器里比先用字符串拼接再传参数要高效。一句话总结不可变的String天然适合多线程共享可变的StringBuilder千万别裸奔共享。这一点写并发代码的时候很容易忽略。5.3 StringBuilder使用的几个实用技巧实际使用中我总结了几条直接能用的建议。循环很长的拼接先把估算长度传给构造器避免扩容损耗。需要换行时用AppendLine而不是Append加Environment.NewLine后者可读性差且容易写漏。一次性拼接大量已知内容时考虑String.Join或String.Concat它们在某些场景下比循环Append更快。不要频繁调用ToString()去检查中间结果每调用一次就创建一个新字符串等于把StringBuilder的优势又丢掉了。如果确定字符串很可能为空sb.Append(Nothing)在某些.NET版本里不会追加任何内容不必特意加判空分支。最后再分享一下个人体会性能优化不是把每一条代码都改成最高级的写法而是先识别出真正的热点再根据字符串长度、拼接次数、并发情况选择合适的工具。我在实际项目里见得最多的反面案例就是所有拼接一律用StringBuilder和所有拼接一律用这两种极端。前者把简单问题复杂化后者在隐蔽的数据增长场景里埋雷。看完今天的实测数据和原理拆解再做选择时应该就有底气多了。毕竟字符串拼接是几乎所有业务系统都绕不开的基础操作把它的性能特性吃透写出的代码才能在数据量翻倍时不掉链子。