最近在研究《javascript高級程序設計》中，有一段關于字符串特點的描述，原文大概如下：ECMAScript中的字符串是不可變的，也就是說，字符串一旦創建，他們的值就不能改變。要改變某個變量的保存的的字符串，首先要銷毀原來的字符串，然后再用另外一個包含新值的字符串填充該變量，例如：

 實現這個操作的過程如下：首先創建一個能容納10個字符的新字符串，然后在這個字符串中填充“Java”和“Script”,最后一步是銷毀原來的字符串“Java”和“Script”,因為這兩個字符串已經沒用了。但是在低版本的瀏覽器(如IE6)中，字符串拼接速度是很消耗一個性能的過程。

由此我就聯想到了Java，在Java中的字符串機制也和js差不多（即創建了就不能改變，要改變只能銷毀原來的值），但是Java有個StringBuffer解決了字符串不可變的問題，js且沒有類似的方法。但是我們可以模擬這種緩沖機制。其原理是利用數組進行拼接，源代碼如下：

 ps:gist地址如下：https://gist.github.com/hehongwei44/fe71f10e4d2d9295aeab

機制我們模擬出來了，但是這個方法和字符串拼接性能上有多少差別了，我們可以測試一下，測試代碼如下：

 測試結果如下：（環境不同，測試結果可能不同）：

1.在以1000次為基數的情況下，進行比較，兩者執行都非常快(基本都是幾毫秒)耗時都差不多，后者以前者相差不會超過10個毫秒。
 2.在以10000次為基數的情況下，執行結果和上面差不多，但是前者在IE6下話費的事件較多。
 3.在以100000次為基數的情況下,字符串拼接在IE6下，明顯花的時間更多，其他瀏覽器相差不大，有的反而比StringBuffer更短。

結論

1.在拼接詞數少于1000次的情況下，大膽的使用前者，一般我們也很少碰到拼接次數上千的情況。
 2.其他瀏覽器對于拼接都沒什么性能問題，主要是IE6，如果拼接次數上萬或者十萬的話，建議單獨對IE6是用StringBuffer模擬。