作为一个有 7 年经验的前端老兵，我原本以为自己和 IE 浏览器 已经彻底"分手"，没想到在新的项目里，又被迫重逢。
说实话，当初接到这个需求的时候，我心里是既无奈又有点小激动------无奈是因为 IE 的坑太多，调试麻烦得要死；小激动是因为终于又能挑战一下自己的技术边界了......不过，这份激动很快就被现实打碎了。
这次折腾的起点是 Vite + React 19。当时我用 Vite 来搭建 React 项目，体验是真的香------启动飞快，构建顺滑，插件丰富，本地调试也非常舒服。几乎能做到你写一行代码，刷新就看到效果的那种爽快感。现代化的开发体验确实让人上瘾，但问题很快出现了：虽然用 babel + polyfill 打包出来的产物在 IE11 上可以勉强跑起来，但本地 dev server 就完全不行了。
想想边写边调试的开发流程，全程卡在这里，效率低得爆炸。IE11 一开就报错，根本连入口都过不去，你能想象我每改一个小功能都得去打包跑一遍吗？心累到爆炸。于是，我脑子一热，决定来一次 激进的降级迁移。
我的思路很直接------既然 Vite 太新、React 19 又前卫，导致 IE 的本地调试不可行，那我就回到更"安全"的老环境：Create React App (CRA) + React 17。在我的设想里，CRA 天生就是 webpack 驱动的，而且在 React 17 的时代，社区里关于 IE11 的解决方案还是挺多的，我几乎是带着一丝"必赢的心态"开始迁移的。
⚙️ 降级迁移的第一步 替换构建工具
迁移第一步就是把 Vite 项目切换到 CRA。光是这一步就让我感受到"现代"和"传统"的差距：
- Vite 配置简单，一个
vite.config.ts就搞定； - CRA 是 webpack 深度封装的，靠
react-scripts驱动，想动配置还得 eject； - Vite 几乎零配置就能跑，CRA 想扩展 webpack 配置，就得冒着各种坑去改。
我最终的做法是新建一个 CRA 项目，把原有代码逐步搬过来。迁移过程中，TypeScript、ESLint、路径别名、环境变量等都要重新适配。每一步都要小心翼翼，稍有不慎就可能导致依赖链错乱或者打包失败。虽然比较麻烦，但至少还能把控得住。说实话，这一步就让我体会到，现代化工具链虽然方便，但回退到传统环境时，每一个细节都像是被放大了几十倍的坑。
🔄 第二步 React 版本回退
接下来就是 React 版本的降级。React 19 虽然还在 RC 阶段，我提前用了，但 IE11 兼容问题完全无解。React 17 至少还有历史案例可参考，于是我硬生生把依赖降到：
ts
"react": "^17.0.2",
"react-dom": "^17.0.2",
"react-scripts": "4.0.3"降完之后，我还是挺有信心的。心理活动大概是这样的："这下应该稳了吧，IE 这次总能跑起来了吧"，但这份自信很快就被残酷现实打得粉碎。
🧪 第三步 IE11 环境测试
项目迁移到 CRA + React 17 后，我满心期待地在 IE11 打开本地开发服务------
然后......依旧是一片报错😂。
最关键的问题是 polyfill 不够。CRA 在 React 17 的时候已经默认放弃了 IE11 支持，需要自己手动补全 polyfill，比如：
react-app-polyfill/ie11core-js/stableregenerator-runtime/runtime
我在配置文件上也一一加上了，但很快就发现问题远不止于此。很多三方依赖库根本没考虑 IE11，代码里满是箭头函数、可选链、Promise.finally 等特性。即便经过 babel 转译，也还是会漏网。
我调试了很久，每一次尝试都像是在拆炸弹：改配置、跑打包、IE报错、查日志、再改配置......循环往复。终于我发现，如果想彻底兼容 IE11，几乎得对整个依赖链做 Babel 处理，这意味着几乎要全盘改 webpack 配置。而 CRA 的封装让这件事变得非常痛苦，真的可以用"手撕 webpack"来形容那种感觉。
🧩 问题剖析：为什么 IE11 这么难伺候？
总结下来，主要卡在三个层面：
- 开发服务层面 Vite 和 CRA 都依赖现代浏览器特性，本地调试时不会去额外编译成 IE 能跑的代码。换句话说，它们默认只服务现代浏览器，IE11 根本不在支持范围。
- 构建产物层面 通过 polyfill + babel，其实是可以让产物在 IE 上运行的。但这只能解决"生产构建"，对本地服务无能为力。
- 周边库兼容性 越来越多第三方库已经完全放弃 IE11，比如部分 UI 库直接用到了 Proxy、ES6+ 新特性，压根没考虑降级。
这意味着，就算主框架能跑通，外部依赖也可能成为"绊脚石"。
🛠️ 我的解法与妥协
经过一番权衡，我最后采取了折中方案：
- 生产环境：依旧使用 Vite + React 19，通过 polyfill + babel 转译来兼容 IE11。
- 本地开发环境：不再强求 IE11，开发调试时使用现代浏览器，最终再在 IE 上做回归测试。
换句话说：
- 开发效率优先，不为了迁就 IE11 而让开发体验倒退。
- 兼容性保障，通过构建结果确保最终产物能在 IE11 打开。
虽然这不是一个完美的方案，但考虑到 IE11 本身就是一个夕阳产品，这是我能找到的最现实的平衡点。
🤔 一些思考
这次折腾让我意识到几个点：
- 时代变了：现在主流工具链几乎都已经抛弃 IE11，继续强行支持只能越来越艰难。
- 兼容策略要现实：别幻想"既要开发体验，又要老古董支持"，多数时候只能取舍。
- 要敢于说"不" ：如果业务真没必要支持 IE11，应该勇敢地推动放弃，而不是无限妥协。
换句话说，前端工程师不仅是写代码的人，还要在技术选型和兼容性上，给出专业判断和底线。
🎬 总结
这场与 IE11 的兼容拉扯，让我深刻体会到"跨时代开发"的痛苦：
- Vite + React 19 已经足够现代化，跑在 IE11 上其实只是"意外之喜"。
- CRA + React 17 的降级尝试，注定只能是回头路。
- 最终解法：接受本地不跑 IE11 的现实，把精力放在产物兼容和测试环节。
也许几年后，当我们再回头看，会觉得这些折腾既好笑又无奈。毕竟，前端的发展速度远比老浏览器的"寿命"要快太多。
所以，当需求里再次冒出"IE11"三个字时，你的第一反应应该是： 👉 "真的有必要吗？"