直觀認識：正面交鋒 
性能測試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 數(shù)據(jù)量） 
第 1 輪測試：用時 12406.25 毫秒 

您注意到了嗎？ 
       String 連接方式在只有 1/100 數(shù)據(jù)的測試下，使用時間30倍于 StringBuilder。因此，基于性能的考量，我們絕不推薦這種方式。而 StringBuilder 較之 StringWriter 略勝一籌，具體的原因?qū)⒃谙挛闹蟹治?。當然，測試存在誤差，但足以說明事實。 

StringWriter 與 StringBuilder：誰是強者 
        StringWriter 位于 System.IO 命名空間內(nèi)，繼承于 TextWriter。在 .Net Reflector 的反編譯結(jié)果中顯示，它的內(nèi)部事實上是采用 StringBuilder 進行連接。無怪乎 StringWriter 會略遜一籌，它原來僅僅是 StringBuilder 的一個適配（可以稱之為 Adapter 模式）。為什么 StringBuilder 擁有如此的效率？ 

您注意到了嗎？ 
在許多地方，需要 StringWriter 而不是 StringBuilder，例如 XmlTextWriter。 

StringBuilder：原因何在 
       關于 System.Text.StringBuilder 的研究，網(wǎng)上已有不少，其主要原理便是預先以非托管方式分配內(nèi)存，保證文本的修改與擴張，不重新創(chuàng)建一個 String 對象。而 String 對象的創(chuàng)建，便是性能瓶頸所在。它的連接效率遠超過 String，不過在少量的文本連接時，顯然 String 編程時更方便些。