安装@babel/runtime-corejs3后是否还需要单独安装core-js作为依赖？

二者的核心逻辑差异 #

你当前同时开启了Babel的两套完全独立的polyfill实现方案，二者的本质区别如下：

• @babel/preset-env + useBuiltIns: usage：全局污染型polyfill方案
  这个方案需要你在项目顶层显式安装core-js作为依赖，实现原理是直接修改全局对象、内置原型链（比如直接给String.prototype补上includes方法），所有代码都可以共享全局的polyfill实现，适合普通业务项目使用。
• @babel/plugin-transform-runtime + corejs: 3：沙箱无全局污染型polyfill方案
  这个方案依赖的@babel/runtime-corejs3本身已经内置了完整的core-js相关实现，不需要你在项目顶层单独安装core-js。它的实现原理是将你代码中用到的新API转成从@babel/runtime-corejs3中引入的独立方法，不会修改全局对象/原型链，不会造成全局污染，更适合公共类库开发场景。

为什么你删除core-js后仍能正常运行 #

两个原因共同导致这个现象：

1. @babel/plugin-transform-runtime的执行优先级高于@babel/preset-env，你代码中所有需要polyfill的API，已经被transform-runtime提前处理成了从@babel/runtime-corejs3引入的形式。你可以看你给出的编译debug日志，明确输出了corejs3 polyfill did not add any polyfill，说明preset-env的polyfill逻辑全程没有触发，自然没有用到你顶层安装的core-js。
2. @babel/runtime-corejs3本身已经打包了完整的core-js实现，它自己的依赖树中已经包含了对应的core-js代码，不需要你在项目顶层显式声明依赖。

最佳实践建议 #

两套polyfill方案不要同时开启，会造成编译后的代码冗余，根据你的场景二选一即可：

• 普通业务项目：保留preset-env的useBuiltIns配置，关闭transform-runtime的corejs选项（只用来复用Babel生成的辅助函数，减少重复代码），此时需要你手动安装core-js作为项目依赖。
• 公共类库开发：关闭preset-env的useBuiltIns配置，开启transform-runtime的corejs: 3配置，此时不需要你手动安装顶层core-js。

内容的提问来源于stack exchange，提问作者NeoZoom.lua