如果有理解错误的地方希望有朋友能指出，谢谢！
String是特殊的引用类型的，更像值类型，StringBuilder的是规规矩矩引用类型的。
首先看这样的对比图，Equals()方法是判断两个变量里面的值是否相等。
下面上代码和注释：
我们通过即时窗口直接获取他们所在的地址是什么？
其中我们发现引用类型sbA和sbB的地址是不一样的，所以通过比较运算符“==”得出的结果是false，而Equals比较值他们的值是“sss”，所以是true。
这里我们发现了一种情况，sA的地址竟然和sB的地址一样，还需要提及一个字符串拘留池的概念，具体概念百度。
我们继续探索，首先我们来看下这三个的地址：
s1和s2都是字符串“哈哈哈”，他们的栈地址也就是一样的，百度过字符串拘留池概念的人应该就明白了
下面我们来看一下传说中s4的地址：
我将是s1和s2拼接后返回给s4后，它的地址是：
然后再做一次操作：
得到s4的地址变化为：
既然拼接之后那我们之前的字符串还在吗？
事实说明s1还是存在的，那我们再换个方式测试一下
第一张图：
第二张图：
你会发现，重新申明的s5的地址竟然也是0x0224b310，应该是微软的垃圾回收没有执行，垃圾回收机制继续百度。
那我们手动的清理一遍，加上代码GC.Collect()：
是不是有点X炸天的感觉，为什么不会被GC？
那我多执行GC几次：
看吧！别天真了，我觉得事实已经验证出来了。
没察觉需要注意的地方？那我们试试引用类型？
第一张图：
第二张图：
s1和s3是不是被顺利回收掉了。
字符串拘留池：如果将同一个字符串赋值给不同的字符串引用，那么系统会为多次分配内存空间，然而这些内存中存储的是同一个字符串。这不仅浪费了宝贵的内存，还极大程度的降低了系统的性能。为了改善程序的性能，.net提出了字符串拘留池机制来解决这一问题。一旦使用了字符串拘留池，当CLR启动的时候，会在内部创建一个容器，容器的键是字符串内容，值时字符串在托管堆上的引用。当一个新的字符串对象需要分配时，CLR首先检测容器中是否包含了该字符串对象，如果已经包含，就直接返回已经存在的字符串对象的引用；如果不存在，则新分配一个字符串对象，并把它添加到内部容器中同时返回该字符串对象的引用。但是当用new关键字显示的申明分配一个字符串对象时，字符串拘留池机制不会再起作用。（这个概念是百度来的）
我的结论：我们在执行大量字符串拼接的时候，尽量使用StringBuilder去处理，如果使用string类型，每一次拼接都会产生一个冗余字段且不能被回收，虽然看起来不多，但是我觉得这是需要注意的地方。尤其看到同事依然选择string去拼接一大串的SQL语句，是有一点弊端的，如果一个系统长期在运行，产生的冗余字段将是不可估量的！
本文仅供参考，如果我理解有误，希望有朋友能告知，谢谢！
扩展：至于刚才写代码为什么用“{0}”这样用参数的形式来去替换，而不是使用string拼接，或者使用StringBuilder，我也反编译了一下看了，底层还是通过StringBuilder下面的AppendFormat来实现的，再往下就是微软的高深动作了，不继续探索了，微软的优化稳妥妥！