string.Concat是可变还是不可变？其合并字符串集合的实现原理

嘿，我来给你拆解一下string.Concat(IEnumerable<string>)的工作原理，帮你搞清楚它和手动用StringBuilder方案的区别~

首先得明确：你已经知道C#里字符串是不可变的，如果直接循环拼接（比如result += item），每一次拼接都会生成新的字符串对象，产生大量临时垃圾，效率很低。但string.Concat和你手动写的StringBuilder方案都避开了这个问题，只不过Concat把优化逻辑封装得更简洁了。

string.Concat(IEnumerable<string>)的具体步骤： #

• 第一步：预计算总长度
  它会先完整遍历一遍你的TheObjectResult这个IEnumerable<string>，把所有非null字符串的长度加起来（遇到null的话，会当成空字符串处理，长度算0）。这一步的目的是一次性算出最终字符串需要的总内存大小，避免后续频繁扩容。
• 第二步：一次性分配内存并复制字符
  拿到总长度后，它会创建一个刚好匹配这个长度的char数组，然后再次遍历TheObjectResult，把每个字符串的字符逐个复制到这个数组里。
• 第三步：生成最终字符串
  最后用这个填满字符的数组直接创建出最终的字符串对象——因为字符串是基于char数组构建的，这一步没有额外的内存浪费。

和手动StringBuilder方案的对比： #

你手动写的StringBuilder代码，如果不指定初始容量，默认初始容量是16。当Append的内容超过当前容量时，StringBuilder会自动扩容（通常是把容量翻倍），这个扩容过程需要重新分配内存并复制现有内容，会产生一点点额外开销。

而string.Concat因为提前算了总长度，相当于帮你直接初始化了一个容量刚好的StringBuilder（或者说用了更底层的内存操作），所以它的效率和你手动先算总长度、再初始化对应容量的StringBuilder是一样的，甚至可能因为是框架内部优化，效率还略高一点。

额外小细节： #

如果你的TheObjectResult里包含null元素，string.Concat会自动把null当成空字符串处理，这点和StringBuilder.Append(null)的行为完全一致，所以两种方案的输出结果是完全相同的。

总结一下：string.Concat本质上是把“计算总长度→分配足够内存→复制所有字符”这个优化流程封装成了一个简洁的方法，代码写起来更短，性能也和最优的StringBuilder实现持平，完全可以放心用~

内容的提问来源于stack exchange，提问作者Saman Gholami