深入探讨IE9浏览器兼容性难题及高效应对方案

哎，说到IE9这个老古董，真是又爱又恨，记得2015年我刚入行做前端的时候，公司还有个政府项目非要兼容IE9——客户那边整个办公室用的还是Windows XP系统，你敢信？那时候我对着浏览器控制台里一堆「对象不支持此属性或方法」的报错,差点没把键盘摔了。

IE9这玩意儿吧，你说它完全落后也不公平，它好歹是微软第一次正经支持HTML5和CSS3的尝试，但那种“半吊子”的支持简直让人抓狂，比如它确实支持border-radius（圆角！），但box-shadow（阴影）就渲染得像是用钢笔胡乱描了个边，而且经常漏掉渐变背景，更别说Flex布局和Grid了——那时候根本想都别想，全是float和display: inline-block搭起来的“积木架构”,代码写得跟迷宫一样。

有一次我做一个简单的模态弹窗，在Chrome里调得完美无缺，结果IE9里点关闭按钮居然没反应，排查了半天才发现是因为我用了addEventListener，而IE9偏得用attachEvent，这还不算，事件对象e.preventDefault()也不支持，非得写e.returnValue = false,那天我一边骂一边在代码里写满了这样的兼容补丁：

if (window.attachEvent) {
  element.attachEvent('onclick', function(e) {
    e.returnValue = false;
  });
} else {
  element.addEventListener('click', function(e) {
    e.preventDefault();
  });
}

现在回想起来都觉得头皮发麻。

还有CSS的坑，IE9不支持rem单位，我只好全部换算成px，媒体查询？勉强可以，但经常断点错乱，最后我只能写两套样式表，一套现代浏览器，一套IE专属,用条件注释硬塞：

<!--[if IE 9]>
  <link rel="stylesheet" href="ie9-fallback.css">
<![endif]-->

那时候团队里有个老工程师跟我说：“别总想着用新特性，在IE里能跑的就是好代码。” 我一开始不服，后来居然也慢慢学会了用条件注释、特性检测和渐进增强——虽然代码看起来臃肿,但至少能运行。

说到Ajax，IE9的XMLHttpRequest倒是基本可用，但一些高级特性比如timeout设置会出问题，而且CORS支持极其脆弱，有一次调第三方接口，在Chrome上秒回，在IE9上就一直挂起，最后发现是对方服务器没有返回IE9认可的Access-Control-Allow-Origin头……最后不得已用JSONP绕了过去。

现在虽然很少有人要求必须兼容IE9了，但那段经历让我明白了一个道理：兼容性从来不是技术问题，而是“人”的问题，客户可能因为预算、习惯或系统封锁而卡在旧技术栈上，开发者能做的不是抱怨，而是理解现实约束，然后用工程思维去填补差距——哪怕代码不那么优雅。

如果你现在还要面对IE9，我的建议是：

• 用工具如Babel或PostCSS做语法降级
• 坚决采用特性检测而非浏览器嗅探
• 必要时用Polyfill，但注意性能损耗
• 最重要的一点：在需求阶段就明确兼容范围,否则后期全是坑。

回头看看，IE9像是一个时代的尴尬缩影——夹在老旧IE6/8和现代浏览器之间，试图进步却又步履蹒跚，而我们这些程序员,不过是在它的漏洞和局限之间勉强搭桥的人罢了。

写于一次深夜加班后，窗外下雨，咖啡已冷，忽然怀念起从前和IE较劲的日子——至少那时候的问题，还能靠一堆hack解决。