直觀認識：正面交鋒
性能測試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 編程時更方便些。
