在本章開始前 我要引入一個例子 來說明這種不徹底的 變態的優化 到底合理還是不合理...
c# 中的 字符串直接量 做的優化 就非常徹底...這種優化我們應該是歡迎的...
string str="franky";
string str2="franky";
在內存中 只有一份 字符串對象 而str和str2 具備相同的一份引用. 很明顯 這非常合理.
string n = "franky", n2 = "franky";
Response.Write((Object.ReferenceEquals(n,n2)).ToString());//True.
那么 一些特殊情況下 有些瀏覽器 為正則表達式直接量也做了類似的優化.
alert(//d/==//d/);//所有瀏覽器都是false 這很合理 因為正則表達式直接量 同 [] 數組直接量 {}對象直接量一樣 都是引用類型
我們再看看哪些情況下哪些瀏覽器做了優化
function f2() {
return //d/;
}
alert(f2() == f2());
//這里的結果就有不同了
ie6 7 8 opear10 safari4 都返回false (我虛擬機里safari3壞了沒做測試.如果誰有 幫忙測下告訴我結果.謝謝 我估計safari3 會返回true.原因是 maxthon3用的引擎貌似就是safari3 的)
但是
firefox 2.0 3.0+ 3.5 3.6 chrome 4 5 opear9 maxthon3 demo版 使用webkit引擎下 都返回true
有趣的地方在于 opera9 做了優化 而opera10 取消了這種優化. 看來至少opera團隊認為這種優化時不恰當的...（變相支持了我的觀點.）
看到這里 你也許會奇怪 是不是 bug而不是所謂優化??？ 也許是閉包對象 出了什么問題或者 是 函數對象上的某些bug引起的？
那么我們看看下面的例子:
for (var i = 0; i < 10; i++) document.writeln(//d/g.test('' + i));
不同瀏覽器 輸出結果的 差異 完全符合上面 是否做優化的分類.
即沒有 做優化的瀏覽器 一律返回true 而作了優化的瀏覽器 則是 true false true false 交替的結果.
我們這里只是一個 循環 ..js中的循環沒有獨立的作用域 更不會產生閉包對象 那么可以肯定 引起這個怪異問題的 根本原因就是某些瀏覽器自作聰明的優化.
可能大家不太理解 test的結果 差異來自哪里... 答案是 test 同 exec 一樣 如果 直接量后面有/g .設置了 global全局查找參數 的話 那么 同一個test對象 會記錄上次 匹配字符的索引位置.下次再 匹配時 會從這個位置開始..如果沒有 則 匹配索引<0 下次在此匹配時 就仍然從0位置字符開始.
所以上面這個測試 使用 exec 也是可以的.
那么 這里 如何避免瀏覽器差異呢？ 簡單的辦法 去掉/g即可
這里我們為了躲避陷阱 就要 記得一個約定. 請盡量不要使用 一個正則直接量 在函數體內 或 循環內. 如果一定要如此 請使用new RegExp('/d',g);這種.
對于exec 盡量用 string.match代替. 因為match 強制你依靠是否有 /g 來全局查找..不會產生歧義.
對于test 如果是循環內 也可以考慮 var reg=//d/; //這里要吧/g去掉..請不要忘記哦
for (var i = 0; i < 10; i++) document.writeln(reg.test('' + i));
事實上這樣用是最合理的辦法 .原因是 這里我們只產生一個正則對象 并反復使用他.. 本質上也是為了優化。但是我們避開了 瀏覽器自己的優化差異 導致的不同結果.
最后我們發現 所謂陷阱 發生主要是 /g使用不當.無論是 exec 還是test都是如此 如果合理使用/g 無論瀏覽器是否存在變態的優化. 執行結果都將是正確的...唯一的區別 只在于 做了優化的瀏覽器 不需要反復產生一個 正則對象然后再垃圾回收 再產生一個正則對象....如此反復而已...
那么我們發現 遵守上面幾個原則的話 這種問題 也都避免了...
