tree shaking 无法消除 polyfill，因其依赖副作用注入、commonjs 模块或转译阶段插入，均脱离静态分析范围；应改用 usebuiltins: 'usage'、显式按需导入或运行时动态加载来减少冗余。
Tree Shaking 本身不处理 polyfill 引入问题，因为它只作用于 ES 模块的静态导入导出结构，而大多数 polyfill（尤其是针对全局环境的）是通过副作用（side effects）方式注入的——比如直接修改 window 或 Array.prototype。这类代码即使没被显式调用，也会在模块执行时立即运行，无法被 Tree Shaking 消除。
polyfill 为什么逃逸 Tree Shaking
原因在于引入方式和模块类型：
- 使用
import 'core-js/stable'或import 'regenerator-runtime/runtime'—— 这些包的入口文件没有export，纯靠执行副作用补丁全局对象，Webpack/Rollup 认为“有副作用”，默认保留； - CommonJS 模块（如旧版
babel-polyfill）无法被静态分析，Tree Shaking 完全失效； - 即便用
useBuiltIns: 'usage'，Babel 插件是在转译阶段按需注入 polyfill，属于语法层插入，不是模块导入，Tree Shaking 不介入这个过程。
如何让 polyfill 更“可摇”
目标不是让 polyfill 被摇掉（它本就不该被摇），而是避免无意义的全局污染和冗余代码。可行做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
改用
useBuiltIns: 'usage'+core-js@3：Babel 根据源码中实际使用的 API（如Promise.allSettled）自动引入最小必要 polyfill，不导入整个 stable； -
显式按需导入：例如只用
import 'core-js/es/promise/all-settled';，避免入口文件的副作用链； -
禁用有副作用的全局 polyfill 入口：确保配置中不出现
import 'core-js';或import 'core-js/shim';这类“全量打补丁”的写法； -
在 Webpack 中标记 polyfill 模块为无副作用（谨慎）：若确认某 polyfill 模块确实无副作用（极少见），可在
package.json中设"sideEffects": false，但core-js等官方包已正确声明，一般无需手动干预。
现代替代方案：运行时检测 + 动态加载
对兼容性要求高、且体积敏感的场景，可绕过构建时 polyfill：
- 用
core-js-pure配合动态import()：只在检测到缺失特性时才加载对应模块，例如：if (!window.Promise?.allSettled) import('core-js-pure/es/promise/all-settled'); - 结合
targets精确配置（如{"chrome": "90", "edge": "95"}），让 Babel 和打包工具知道无需为旧环境补丁，从根本上减少 polyfill 需求。
关键要分清：Tree Shaking 是模块粒度的死代码消除，polyfill 是环境适配逻辑。解决思路不在“摇”，而在“按需注入”和“精准目标”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
