在前端开发中，兼容性问题，尤其是面对老旧的IE浏览器，总能给我们带来意想不到的“惊喜”。今天想分享一个最近遇到的，由一行我们习以为常的 console.log 所引发的诡异BUG，整个排查过程可谓一波三折。
背景：一个“简单”的需求
故事的起点，是在一个颇有年头的、基于IE兼容模式运行的内网系统中。我们的任务是通过 window.open 弹出一个新窗口，来嵌入我们的新功能模块。为了实现与主窗口的交互，我们重写了原系统中的 window.showModalDialog 方法，将其替换为 window.open。
现象：离奇的BUG
改造完成后，怪事发生了。通过新方法打开的窗口，有时会被浏览器直接拦截，有时虽然能成功打开，但页面内的脚本无法正常执行，导致后续的业务逻辑中断。
最令人费解的是，如果打开浏览器的开发者工具（F12），然后在控制台里手动执行完全相同的 window.open 代码，弹窗却能完美地正常工作。这让我们一度怀疑是代码执行时机或作用域的问题。
排查：一条曲折的弯路
我们开始了漫长的排查之路：
- 怀疑文档模式不一致：我们发现，主窗口的文档模式是IE5，而
window.open打开的窗口是Edge模式。我们尝试强制新窗口使用IE5模式，但问题依旧。 - 怀疑系统兼容性设置：我们想，是不是可以请求客户移除整个系统的IE兼容性设置，让所有页面都在Edge模式下运行？这个方案从根源上解决了问题，但由于影响范围太大，被客户方直接拒绝。
- 怀疑
window.open本身：我们又回到原点，思考能否在不替换showModalDialog的前提下注入我们的脚本。在咨询了团队里的资深同事后，确认此路不通。
排查陷入了僵局，我们似乎尝试了所有可能的方向，但都无法定位问题根源。
真相：意想不到的“元凶”
在几乎山穷水尽时，我们抱着试一试的心态，做了一个看似毫不相关的操作：全局搜索并删除了我们代码里所有的 console.log 语句。
奇迹发生了——问题竟然被完美解决！
原因分析与总结
真相大白后，我们很快找到了原因。在IE8及更早版本的浏览器中，console 对象只有在开发者工具（F12）被打开时才存在。如果开发者工具未打开，代码执行到 console.log 这一行时，会因为找不到 console 对象而直接抛出错误，导致后续的所有JS代码都停止执行。
这就是为什么当F12打开时一切正常，而正常使用时却会出问题的根本原因。
这次经历给我们上了一堂生动的课：在面对遗留系统，尤其是老版本IE时，任何我们现在看来天经地义的API，都可能是一个深埋的“巨坑”。对于要兼容低版本IE的项目，线上代码中移除 console.log，或者对其进行封装判断，应成为一条必须遵守的军规。
最终解决：
删除代码里所有的console.log
原因分析：console.log原为Firefox的专利，ie是从版本号8起才新增的console；在ie8之前使用console.log会导致后续语句无法运行
https://www.cnblogs.com/sxn104/p/sxn104.html