处理 javascript tree shaking 中的全局副作用，核心做法是确保模块在导入时不执行任何非导出逻辑，并将具有副作用的代码显式标记或隔离。具体而言，应移除文件顶层的立即执行函数、直接的全局变量赋值以及同步的网络请求；对于必须执行的初始化代码，需使用打包工具（如 webpack）提供的 sideeffects 配置项进行声明，或在入口文件中单独引入以阻断摇树优化对该文件的剔除。
如何识别并消除模块顶层的隐式副作用
模块顶层的隐式副作用主要指在模块被加载（import/require）时立即运行的代码，这些代码会修改全局状态或产生外部影响，导致打包工具无法安全地删除该模块。要消除这类副作用，开发者需要检查源文件，将原本散落在顶层的逻辑提取到具体的函数中，并确保这些函数仅在显式调用时才执行。例如，避免在模块顶部直接调用 fetch 或修改 window 对象，而是将这些操作封装在导出的 API 内部。
// bad.js - 包含隐式副作用
console.log('Module loaded'); // 副作用：打印日志
window.myGlobal = true; // 副作用：修改全局变量
export const value = 1;
// good.js - 无隐式副作用
export function init() {
console.log('Module initialized');
window.myGlobal = true;
}
export const value = 1;
在上述对比中，bad.js 即使未被导入，其顶层代码也会执行，因此打包工具必须保留它。而 good.js 将副作用封装在 init 函数中，如果项目中没有调用 init，且没有其他代码引用 value，那么整个模块都可能被 Tree Shaking 移除。这种重构使得副作用变得可控，符合纯模块的设计原则。
如何在构建工具中显式声明剩余的全局副作用
当某些库不可避免地带有全局副作用（如 polyfill 或样式注入）时，可以通过配置打包工具的 sideEffects 字段来告诉优化器哪些文件是安全的。在 package.json 中设置 "sideEffects": false 表示所有模块都是纯函数式的，可以安全地进行摇树优化。如果只有特定文件有副作用，则列出这些文件的路径，例如 ["./src/styles.css"]。这样，除了列出的文件外，其他未使用的 JS 模块仍会被剔除。
{
"name": "my-library",
"sideEffects": [
"./src/polyfills.js",
"*.css"
]
}
通过上述配置，构建工具在处理 my-library 时，会跳过对 polyfills.js 和 CSS 文件的 Tree Shaking，确保它们始终被包含在最终 bundle 中。而对于其他 JS 文件，如果没有被导入，或者导入的导出项未被使用，它们将被安全地移除。这种方法既保留了必要的全局初始化逻辑，又最大化了代码压缩的效果。
基于入口文件引入 Polyfill 时的副作用处理
在实际项目中，通常需要在应用入口处引入全局 Polyfill 以兼容旧浏览器。这种情况下，Polyfill 文件本身具有强烈的全局副作用，但它是按需加载的。为了正确处理这种情况，应在应用的唯一入口文件（如 main.js）中直接导入 Polyfill，而不是在业务组件中分散引入。由于入口文件通常不会被 Tree Shaking 完全移除（因为它是启动点），其中的导入语句会触发 Polyfill 的执行。
// main.js
import 'core-js/stable'; // 全局副作用：注入 Polyfill
import './styles/main.css'; // 全局副作用：注入样式
import App from './App'; // 纯模块：可被摇树
new App().mount('#root');
在此场景中，core-js 和 CSS 文件虽然引入了副作用，但因为它们在入口文件中被显式引用，所以不会被误删。而 App 组件及其依赖项，如果其中存在未使用的函数或变量，依然可以被正常 Tree Shaking。关键在于区分“必须存在的副作用”和“可优化的冗余代码”，前者通过入口集中管理，后者通过模块化重构消除。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
