解决corejs兼容性问题的实战经验与优化思路

项目初期的技术选型

最近刚做完一个企业级管理系统，这个项目需要兼容IE11和一些老旧浏览器。说实话，一开始我挺头疼的，因为现代前端开发基本都默认支持ES6+了，但客户那边坚持要兼容老版本浏览器。

经过一番调研，我选择了core-js作为polyfill方案。为啥选它呢？主要是因为它支持按需加载，而且社区活跃度高。相比之下，babel-polyfill已经不推荐使用了，而直接用@babel/runtime的话，覆盖范围又不够全面。

最大的坑：性能问题

开始没想太多，直接在入口文件引入了完整的core-js：

import "core-js";

结果一跑起来就发现问题了——打包后的vendor.js居然有1.2MB！这明显是把所有polyfill都打进去了。后来查了下文档才发现，这种全局引入方式确实会包含大量用不到的功能。

折腾了半天，最后改成按需引入的方式：

import "core-js/features/array/includes";
import "core-js/features/string/pad-start";
import "core-js/features/promise";

这样只引入项目中实际用到的功能，最终vendor.js减到了300多KB，效果立竿见影。

另一个麻烦事：版本兼容

中途还遇到个奇葩问题，测试环境一直报错说Promise未定义。排查了很久才发现，原来是core-js的版本问题。项目里用了两个不同的库，一个依赖core-js@2，另一个依赖core-js@3，导致冲突了。

解决方法是统一版本，在package.json里明确指定：

"resolutions": {
  "core-js": "^3.30.0"
}

这里要注意，如果你用的是yarn，记得运行yarn install --flat来确保版本统一。npm用户可能需要额外安装npm-force-resolutions插件。

核心代码实现

最后总结了一套比较稳妥的配置方案，分享给大家：

// polyfills.js
import "core-js/modules/es.array.includes";
import "core-js/modules/es.array.find";
import "core-js/modules/es.object.assign";
import "core-js/modules/es.promise";
import "core-js/modules/es.string.pad-start";
import "core-js/modules/es.string.trim";
import "core-js/modules/es.symbol";
import "core-js/modules/web.dom-collections.for-each";

// IE11还需要额外处理fetch
import 'whatwg-fetch';

然后在webpack配置里做条件加载：

const isProduction = process.env.NODE_ENV === 'production';

module.exports = {
  entry: {
    main: './src/index.js',
    polyfills: isProduction ? './src/polyfills.js' : undefined,
  },
  // 其他配置...
};

回顾与反思

整体来看，这个方案还是不错的。通过按需加载，既保证了兼容性，又控制了打包体积。不过也有一些遗憾的地方，比如：

• 某些边缘case还是会出现兼容问题，特别是IE11的console报错有时不太准确
• 动态导入的模块偶尔会有polyfill加载顺序的问题，这个暂时还没找到完美的解决方案
• 维护成本略高，每次新增功能都要检查是否需要补充对应的polyfill

虽然有些小瑕疵，但总体影响不大。毕竟现在主流趋势都是逐步放弃对老旧浏览器的支持，这个方案也算是个过渡时期的权宜之计吧。

以上是我踩坑后的总结，希望对你有帮助。如果大家有更好的实践方案，欢迎在评论区交流。