全量polyfill一次性引入所有垫片，按需polyfill仅加载实际使用的api；前者简单兜底但体积大、污染全局，适合独立web应用；后者由babel自动注入、零污染、体积小，是现代项目主流选择。
全量 Polyfill 是一次性引入所有垫片，按需 Polyfill 则只加载代码里实际用到的 API 垫片。关键区别不在“要不要加”，而在于体积、污染和适用场景。
全量 Polyfill：简单粗暴，适合独立应用
典型做法是入口文件顶部手动引入：import 'core-js/stable'; import 'regenerator-runtime/runtime';。Babel 不参与注入，靠你主动加载整个 core-js 3 的稳定版 polyfill。
- 优点：配置极简，兼容性兜底强，尤其适合管理权完全在手的 Web 应用（比如内部管理系统、营销页）
- 缺点：不管用没用，Promise、Map、Array.prototype.flat 全都打包进来；会改写全局原型（如给 Array.prototype 加方法），存在污染风险；多个模块重复使用同一 API 时，polyfill 仍只加载一次，但体积不可控
- 不推荐用于 npm 包或 SDK 类项目——别人集成你的库时，可能已有同类 polyfill，冲突或冗余难以避免
按需 Polyfill：精准注入，现代项目的主流选择
核心是配置 @babel/preset-env 的 useBuiltIns: "usage" + corejs: 3，Babel 在编译时扫描源码 AST，自动识别并插入所需 polyfill 模块。
- 例如写了
const arr = [1,2].includes(2)，Babel 就只引入core-js/modules/es.array.includes，不会带进es.string.padStart - 不污染全局环境（默认行为），所有 polyfill 都以模块方式局部引入，更安全
- 配合
.browserslistrc（如"> 0.25%, not dead"）可进一步缩小范围，实测能减少约 40% 的 polyfill 体积 - 注意：必须确保入口文件里 不手动 import core-js，否则会和 Babel 的自动注入冲突，导致重复或失效
还有个中间方案：runtime 方式（适合工具库）
用 @babel/plugin-transform-runtime + @babel/runtime，它不处理全局 API（如 Promise），而是把辅助函数（如 _classCallCheck、_defineProperty）和部分实例方法（如 Array.from）转成对 @babel/runtime 的依赖。
- 不修改全局，零污染，天生适合封装成 npm 包
- 但它不解决
fetch、Promise这类浏览器原生全局对象的问题——这些还得靠core-js补齐 - 常见组合是：应用层用
useBuiltIns: "usage"，工具库层用transform-runtime
怎么选？看项目角色
如果你开发的是一个要上线的完整网页应用，选 useBuiltIns: "usage"；如果是给别人用的 UI 组件库或工具函数包，禁用全局 polyfill，用 transform-runtime + 文档注明“需宿主提供 Promise 等基础支持”；只有调试或兼容极端老旧环境（如强制支持 IE9）时，才考虑全量引入并仔细评估体积与风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
