直观认识：正面交锋  性能测试1：StringBuilder  第 1 轮测试：用时 312.5 毫秒  第 2 轮测试：用时 421.875 毫秒  第 3 轮测试：用时 453.125 毫秒  第 4 轮测试：用时 421.875 毫秒  第 5 轮测试：用时 453.125 毫秒  性能测试2：StringWriter  第 1 轮测试：用时 406.25 毫秒  第 2 轮测试：用时 453.125 毫秒  第 3 轮测试：用时 421.875 毫秒  第 4 轮测试：用时 437.5 毫秒  第 5 轮测试：用时 437.5 毫秒  性能测试3：String（1/100 数据量）  第 1 轮测试：用时 12406.25 毫秒  您注意到了吗？         String 连接方式在只有 1/100 数据的测试下，使用时间30倍于 StringBuilder。因此，基于性能的考量，我们绝不推荐这种方式。而 StringBuilder 较之 StringWriter 略胜一筹，具体的原因将在下文中分析。当然，测试存在误差，但足以说明事实。  StringWriter 与 StringBuilder：谁是强者          StringWriter 位于 System.IO 命名空间内，继承于 TextWriter。在 .Net Reflector 的反编译结果中显示，它的内部事实上是采用 StringBuilder 进行连接。无怪乎 StringWriter 会略逊一筹，它原来仅仅是 StringBuilder 的一个适配（可以称之为 Adapter 模式）。为什么 StringBuilder 拥有如此的效率？  您注意到了吗？  在许多地方，需要 StringWriter 而不是 StringBuilder，例如 XmlTextWriter。  StringBuilder：原因何在         关于 System.Text.StringBuilder 的研究，网上已有不少，其主要原理便是预先以非托管方式分配内存，保证文本的修改与扩张，不重新创建一个 String 对象。而 String 对象的创建，便是性能瓶颈所在。它的连接效率远超过 String，不过在少量的文本连接时，显然 String 编程时更方便些。