在本章开始前 我要引入一个例子 来说明这种不彻底的 变态的优化 到底合理还是不合理...
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 无论浏览器是否存在变态的优化. 执行结果都将是正确的...唯一的区别 只在于 做了优化的浏览器 不需要反复产生一个 正则对象然后再垃圾回收 再产生一个正则对象....如此反复而已...
那么我们发现 遵守上面几个原则的话 这种问题 也都避免了...
本文浏览器中的正则表达式陷阱说明到此结束。抱最大的但愿，为最大的勤奋，做最坏的筹算。小编再次感谢大家对我们的支持！
