4. StringBuilder高效字符串处理

一、 程序员的噩梦：疯狂的内存分配

写代码的时候，你是不是干过这种事：在一个循环里不停地往字符串里加东西，比如凑出一个1000行的日志文件，或者拼凑一个HTML网页的代码。

刚开始，你自信满满地写着：

string html = "";
for (int i = 0; i < 10000; i++)
{
    html += "<div>内容" + i + "</div>";
}

看着代码跑通，你感觉没问题。直到有一天，你的程序变卡了，电脑风扇开始像直升机一样狂转，然后啪一下弹出了 OutOfMemoryException（内存溢出）的报错窗口。

这简直是在给CPU喂毒药。

这就好比你拿纸笔写日记，每写一句话，你就得把整本日记撕掉，把新内容誊抄上去。写一千行，你就得撕一千次纸，还要把以前的内容重新抄一千遍。

永远别在循环里搞字符串拼接，除非你想让CPU陪你通宵加班。

二、 草稿板机制：StringBuilder的登场

为了避免这种“撕书重抄”的惨剧，C#给我们准备了一个好帮手——StringBuilder。它的核心思想很朴实：先在脑子里过一遍，最后再写上去。

如果你把 string 比作“纸质文件”，一旦写错要全部重写；那 StringBuilder 就是你的“草稿板”。你可以在上面随意涂鸦、修改，最后满意了再一次性整理成文。

它的底层是个动态数组。一开始给你一小块空地，不够用了，它就自动扩容，把之前的旧内容搬过去，再写新的。这个过程对用户（也就是你）来说是无感知的，但在内存里，它就在旁边悄悄等着，不搞乱其他的。

三、 实战对比：谁才是真正的性能之王

咱们来个实打实的对比。假设我要生成1000条数据的日志，看看到底谁跑得快。

旧方法（慢得像蜗牛）：
直接在循环里用 + 号拼接。这种做法会让垃圾回收器（GC）忙得要死，因为它要不停地清理掉那些中间产生的、用完即弃的“垃圾字符串”。
内存占用：爆炸。
运行速度：惨不忍睹。

新方法（StringBuilder）：
我们需要用到 System.Text 命名空间，用 new StringBuilder() 初始化它，然后用 .Append() 往里加东西。
内存占用：平稳，只增不减。
运行速度：像装了加速器。

using System.Text;

// 1. 像买车一样，得先领个牌照
StringBuilder sb = new StringBuilder();

// 2. 像往水桶里倒水一样，一路Append下去
for (int i = 0; i < 10000; i++)
{
    sb.AppendLine($"这是第 {i} 条日志，时间戳是 {DateTime.Now.Ticks}");
}

// 3. 拿到手再转成字符串
string finalResult = sb.ToString();

代码一跑，结果一目了然。StringBuilder不仅没让GC报警，速度更是原地起飞。

四、 灵魂拷问与避坑指南

这里有个坑得提醒一下：不要为了用而用。

如果只是简单地拼接 string a = "Hello" + "World";，直接用 + 号完全没问题，编译器比你还聪明，会自动把它优化成一行代码。

真正的战场在“循环”里，在“大数据量”处理里。 比如循环拼接10000次，或者拼接一段超长的XML/JSON配置。

另外，StringBuilder 是可变的。如果你不想让它在内存里占太大地方，其实可以给个建议容量：

// 告诉它：“我心里有数，大概要放个500个字符，别到时候抢不到位置”
StringBuilder sb = new StringBuilder(500);

五、 总结

别再对字符串拼接视而不见了，它们正在悄悄拖垮你的程序。

一旦遇到“循环拼接”、“大量拼接”的场景，请像保护自己的钱包一样，坚决捍卫 StringBuilder 的地位。记住，高效的代码，不是算得最快的，而是让机器“不累”的。

今天的作业很简单：回去把你代码里所有的循环字符串拼接都找出来，把它们统统换掉。

动手试试吧！