本文关键词：自己做的网站如何兼容ie11
说实话，每次听到“兼容IE11”这几个字，我这头发都要掉一把。
现在都2024年了，还有人在用IE11？
还真有。
特别是那些做政府项目、银行后台、或者传统制造业ERP系统的同行。
客户不在乎你技术多先进，他们只在乎那个该死的弹窗能不能打开，表单能不能提交。
我最近就接了个私活，给一个老厂做内部数据看板。
前端用的Vue3，后端Node.js。
本来我想着，直接告诉客户：“IE早淘汰了，别用了。”
结果客户甩过来一张红头文件，说上级检查必须兼容。
没办法，硬着头皮上。
今天就把我踩过的坑，还有最后怎么搞定的经验，毫无保留地分享出来。
希望能帮正在死磕的你省点头发。
首先，你要认清一个现实。
Vue3、React 18这些现代框架，原生是不支持IE11的。
因为IE11不支持Promise，不支持箭头函数，不支持let/const，甚至连flex布局都做得一塌糊涂。
你直接扔上去，浏览器直接给你一片空白，或者满屏报错。
所以，第一步，必须引入Polyfill。
这是地基。
不打好地基，楼盖不高。
我推荐用core-js和babel-polyfill。
在package.json里配置一下babel。
记得把presets改成env，并且指定targets为ie 11。
这一步很多人会忽略，导致编译后的代码还是ES6语法，IE直接懵圈。
编译通过后，别急着高兴。
这时候打开IE11，你会发现，虽然不报错了，但样式全乱。
对，这就是第二步要面对的：CSS兼容性问题。
IE11对CSS Grid支持极差，甚至不支持。
如果你用了Grid布局，在IE里基本就是灾难现场。
我的建议是，关键布局用Flexbox，或者传统的float+clear。
虽然写起来麻烦点，但稳妥。
还有，IE11不支持CSS变量。
如果你的主题色是用var(--primary-color)定义的，在IE里会失效。
这时候只能退回到传统的class命名，或者用JS动态注入样式。
虽然土，但有效。
接下来是最头疼的JS逻辑。
Promise在IE里是没有的。
你需要引入promise-polyfill。
还有fetch API，IE也不支持。
这时候axios就派上用场了，或者引入whatwg-fetch。
我之前的项目里，因为没处理好异步请求的兼容，导致数据加载一直转圈。
查了两天bug，最后发现是Promise没polyfill到位。
那种绝望感，懂的都懂。
另外，Vue3的响应式原理在IE11里也有坑。
IE11不支持Proxy，所以Vue3在IE里根本跑不起来。
如果你非要用Vue3，必须借助vue-polyfill或者降级到Vue2。
我当时为了赶进度，没敢动底层，而是把核心功能拆出来，用原生JS写了一些兼容层。
虽然代码丑了点，但能跑。
还有一点，图标字体。
很多项目用iconfont，但在IE11里，woff2格式可能加载失败。
记得把woff2降级成woff，或者ttf。
别嫌麻烦，这是细节决定成败。
最后，测试环节。
千万别只在Chrome里调试完就上线。
去装一个IE11虚拟机，或者用微软提供的VirtualBox镜像。
真机测试很重要。
有些样式问题，在模拟器里看不出来，只有真机才会暴露。
我有一次就是因为在模拟器上看着正常，结果客户用真机打开，发现按钮重叠了。
被客户骂得狗血淋头。
总结一下，自己做的网站如何兼容ie11，核心就三点：
1. 编译配置要改，babel-polyfill不能少。
2. CSS布局要降级，Flexbox慎用，Grid别碰。
3. JS API要补齐，Promise和Fetch都要polyfill。
这活儿确实恶心，但做完之后，你对前端底层原理的理解会深一层。
毕竟，能搞定IE11的人，搞定现代浏览器简直是小菜一碟。
如果你也在为这个头疼，不妨试试上面的方法。
虽然过程痛苦，但结果还是值得的。
至少，你能拿着工资，少掉两根头发。
加油吧，前端人。
这条路，虽然泥泞，但风景独好。
希望这篇经验贴，能帮你少走点弯路。
如果有其他兼容问题，欢迎在评论区留言，我们一起探讨。
毕竟，前端这条路，一个人走得快，一群人走得远。
别怕麻烦，别怕报错。
每一个Bug，都是你成长的阶梯。
共勉。
