核心是将 polyfill 拆至独立入口文件（如 src/polyfills.js）并显式导入，配合 package.json 中精确声明 sideEffects 范围，确保构建工具识别其副作用、保留必要代码，同时不影响其他模块的 Tree Shaking。
处理 Polyfill 引入对 Tree Shaking 的副作用影响，核心是让构建工具（如 Webpack、Vite）明确知道哪些文件“必须执行”，从而避免误删，同时又不破坏其他模块的摇树优化。
把 Polyfill 拆到独立入口文件
不要在通用工具函数或主入口里直接 import 'core-js/stable' 或 require('regenerator-runtime')。这类导入没有 export，纯靠执行产生全局效果，Webpack 会将其视为有副作用的模块——但若未显式声明，就可能连带保留大量未使用的代码。
- 新建 src/polyfills.js，只放 polyfill 相关导入：
import 'regenerator-runtime/runtime';
- 在应用最顶层（如 main.js）显式导入：import './polyfills.js';
- 这样既保持副作用可控，又便于后续在
package.json中精准声明。
在 package.json 中正确配置 sideEffects
如果库本身提供 polyfill 功能，需在 package.json 中声明其副作用范围，不能简单设为 false。
- 全部无副作用 →
"sideEffects": false（但含 polyfill 就不适用） - 仅 polyfill 文件有副作用 →
"sideEffects": ["./src/polyfills.js", "./polyfill.ts"] - 支持通配 →
"sideEffects": ["*.polyfill.js", "polyfills/**/*"]
该配置告诉 Webpack：只有这些文件必须执行，其余模块可放心做静态分析和摇树。
避免在工具模块中隐式触发 polyfill
有些封装函数看似“纯”，实则依赖了被 polyfill 补丁过的原生方法（比如用到了 Array.prototype.flatMap），而该 polyfill 又没被显式引入——这时运行时可能出错，但构建时却无法预警。
- 确保 polyfill 加载早于任何业务代码（通常放在 HTML 的 script 标签最前，或 entry 点第一行）
- 不要在导出函数内部动态加载 polyfill（如
if (!Array.prototype.flatMap) import(...)），这属于运行时副作用，Tree Shaking 无法识别 - 若需条件加载，改用构建时环境判断（如通过
process.env或 definePlugin 注入标志）
使用现代替代方案降低 polyfill 依赖
减少副作用源头，比兜底处理更有效。
- 目标浏览器明确时（如只支持 Chrome 90+），关闭不必要的 polyfill（Babel preset-env 的
targets配置） - 用
core-js/stable/array/flat-map替代全量core-js/stable，按需引入 - 优先使用原生已支持的 API，辅以轻量检测（如
typeof Promise !== 'undefined'）而非无脑注入
