JavaScript中Tree-shaking失效的场景及其优化对策

Tree-shaking 失效主因是动态导入、条件导出、隐式副作用、CommonJS 混入及开发配置不当；需坚持纯 ESM、显式声明 sideEffects、禁用 Babel 转译 export、确保生产模式构建。Tree-shaking 失效，往往不是因为代码写得“不够函数式”，而是某些看似无害的写法或构建配置，悄悄切断了静态分析的路径。核心在于：Webpack 或 Rollup 依赖 ESM 的静态结构（如 import/export）来识别未使用导出；一旦出现动态、副作用或非标准引用，摇树就无法安全剔除。动态导入或条件导出破坏静态可分析性当模块加载路径、导出名或是否导出由运行时逻辑决定时，打包工具无法在构建期判断哪些代码会被用到。避免 import(`./module-${type}.js`) 这类动态导入（除非明确需要 code-splitting），它会让整个模块及其依赖逃逸 tree-shaking 不要在 export 前加条件判断，例如：??const utils = { a: () => 1, b: () => 2 };??if (process.env.NODE_ENV === 'dev') export const devUtils = utils;这种写法让 devUtils 变成一个“可能存在的导出”，工具只能保守保留全部 推荐改为纯 ESM 风格：每个功能独立命名导出，按需引入，不包裹在对象或条件中存在未声明的副作用（sideEffects: false 不生效）即使你写了 "sideEffects": false，只要模块里有隐式副作用（如执行全局赋值、修改原型、发起请求），打包工具就必须保留整个模块——因为它不敢删“可能影响行为”的代码。检查 node_modules 中第三方库是否声明了 sideEffects 字段；没声明则默认视为有副作用，整包保留 自己写的工具模块，确保不带副作用：避免 window.xxx = ...、Array.prototype.xxx = ...、console.log()（尤其在顶层）、fetch() 等 如有必要保留副作用，显式标注："sideEffects": ["*.css", "*.scss"]，其余文件才可被安全摇掉CommonJS 混入或 Babel 转译污染 ESM 结构ESM 是 tree-shaking 的前提。若项目中混用 require() / module.exports，或 Babel 错误地将 export 编译为 Object.defineProperty(exports, ...)，静态分析就会失效。 幻导航网 发现优质实用网站,开启网络探索之旅！