core-js 3 落地后Babel 的 polyfill 配置到底该怎么改【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js一个团队升级 core-js 3 后首屏 JS 直接涨了三四百 KB——原因是 polyfill 入口还停留在 core-js 2 的写法。我们把 Babel 集成配置重做了一遍polyfill 体积缩减了大约三分之二。这篇把正确的改法讲清楚顺带说清楚每一步为什么。import 那一行写在哪是迁移第一步core-js 2 时代大家习惯import core2或者引babel/polyfill这两个到 3 里都不推荐了。更关键的是包的拆分现在core-js本体是全局 polyfill约 500KB 的完整稳定库core-js-pure提供不污染全局命名空间的函数式调用core-js-compat则是纯数据源——Babel 判断该注哪些全靠它pure 入口的用法见这里。⚠️ 迁移时最容易踩的坑就一个图省事直接import core-js/stable然后让打包器原样带走。现代浏览器上这几乎全是浪费。正确姿势是把注什么的决定权交还给 Babel而不是入口文件。Babel 实际给你注入了什么useBuiltIns: usage生效后Babel 会扫描代码里每一处 API 调用再对照 browserslist 配置决定是否在文件顶部加一条 polyfill 导入。core-js 3 时代这份判定数据的来源换成了core-js-compat内置的 compat 数据精度比旧版 compat-table 高得多。所以配置的重心落在 targets 上// babel preset-env targets: 1%, not dead, useBuiltIns: usage, corejs: 3如果 targets 里还留着 IE 11Promise、Symbol 全家桶都会被拉进来改成现代基线后注入量往往直接减半。entry 还是 usage先看你的构建速度这是争议最多的选择也就是 useBuiltIns entry vs usage 之争。entry 是你在应用顶部手写import core-js/stableBabel 只做减法按 targets 把入口里多余的模块裁掉。好处是构建快、没有逐文件扫描坏处是哪怕某 API 你一行没写它照样进包。usage 则相反按需注入polyfill 体积优化做到最极致代价是 transform 变慢且动态构造出来的调用它扫不到。我的取舍追求包体最小就上 usage构建时长是硬指标就用 entry但必须配精确的 targets。跑一次 compat验证有没有多注别信配置跑一下。core-js-compat 用法很简单import compat from core-js-compat; const { list, targets } compat({ targets: 1% });list是必须注入的模块清单targets则标出每个模块具体缺在哪些浏览器的哪些版本。把它和产物里实际 import 的 polyfill 模块做个 diff多出来的每一项都能直接定位到原因——是 targets 漏了版本还是某处动态调用骗过了静态扫描。 收尾给个能立刻执行的行动把项目的 browserslist 查询填进targets跑一次上面的compat()再对比 bundle 里 polyfill 的实际大小——对不上账的那几个模块就是你下一次优化的起点。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/5 17:52:26 · 阅读 1.2k core-js 3 落地后，Babel 的 polyfill 配置到底该怎么改
core-js 3 落地后Babel 的 polyfill 配置到底该怎么改【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js一个团队升级 core-js 3 后首屏 JS 直接涨了三四百 KB——原因是 polyfill 入口还停留在 core-js 2 的写法。我们把 Babel 集成配置重做了一遍polyfill 体积缩减了大约三分之二。这篇把正确的改法讲清楚顺带说清楚每一步为什么。import 那一行写在哪是迁移第一步core-js 2 时代大家习惯import core2或者引babel/polyfill这两个到 3 里都不推荐了。更关键的是包的拆分现在core-js本体是全局 polyfill约 500KB 的完整稳定库core-js-pure提供不污染全局命名空间的函数式调用core-js-compat则是纯数据源——Babel 判断该注哪些全靠它pure 入口的用法见这里。⚠️ 迁移时最容易踩的坑就一个图省事直接import core-js/stable然后让打包器原样带走。现代浏览器上这几乎全是浪费。正确姿势是把注什么的决定权交还给 Babel而不是入口文件。Babel 实际给你注入了什么useBuiltIns: usage生效后Babel 会扫描代码里每一处 API 调用再对照 browserslist 配置决定是否在文件顶部加一条 polyfill 导入。core-js 3 时代这份判定数据的来源换成了core-js-compat内置的 compat 数据精度比旧版 compat-table 高得多。所以配置的重心落在 targets 上// babel preset-env targets: 1%, not dead, useBuiltIns: usage, corejs: 3如果 targets 里还留着 IE 11Promise、Symbol 全家桶都会被拉进来改成现代基线后注入量往往直接减半。entry 还是 usage先看你的构建速度这是争议最多的选择也就是 useBuiltIns entry vs usage 之争。entry 是你在应用顶部手写import core-js/stableBabel 只做减法按 targets 把入口里多余的模块裁掉。好处是构建快、没有逐文件扫描坏处是哪怕某 API 你一行没写它照样进包。usage 则相反按需注入polyfill 体积优化做到最极致代价是 transform 变慢且动态构造出来的调用它扫不到。我的取舍追求包体最小就上 usage构建时长是硬指标就用 entry但必须配精确的 targets。跑一次 compat验证有没有多注别信配置跑一下。core-js-compat 用法很简单import compat from core-js-compat; const { list, targets } compat({ targets: 1% });list是必须注入的模块清单targets则标出每个模块具体缺在哪些浏览器的哪些版本。把它和产物里实际 import 的 polyfill 模块做个 diff多出来的每一项都能直接定位到原因——是 targets 漏了版本还是某处动态调用骗过了静态扫描。 收尾给个能立刻执行的行动把项目的 browserslist 查询填进targets跑一次上面的compat()再对比 bundle 里 polyfill 的实际大小——对不上账的那几个模块就是你下一次优化的起点。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考