Tree Shaking 依赖代码写法、构建配置、依赖选择三者协同，需通过打包产物反推问题，再逐层修正：先用工具定位未摇掉代码，再检查导入方式、清理副作用、验证构建配置。
Tree Shaking 不是配置开个开关就自动生效的“一键优化”，它依赖代码写法、构建配置、依赖选择三者协同。真正有效的复盘与调优，必须从打包产物反推问题根源，再逐层修正。以下是经过多个生产项目验证的经典路径。
一、先看结果：用工具定位没被摇掉的“顽固代码”
不验证，一切优化都是假设。必须打开打包产物分析真实情况：
- 用 source-map-explorer 可视化分析 dist 目录下 JS 文件，直接看到 lodash-es 里哪些函数被打进了 bundle（比如 debounce 没用，却出现了 throttle、cloneDeep）
- 在 Webpack 配置中启用 stats: 'verbose'，构建后搜索 unused harmony export，确认哪些导出已被标记但未被移除
- 检查是否出现 side effect in module 提示——这说明某模块因副作用被整块保留，哪怕只用了其中一行
二、查导入方式：90% 的失效源于错误 import
Tree Shaking 的起点是静态可分析性，而 import 写法直接决定分析能否成立：
- 禁用 namespace 导入：
import * as utils from './utils'→ 整个模块被视为“被使用”，无法摇树 - 避免 默认全量导入：
import _ from 'lodash'→ 即使只调用 _.debounce，Webpack 也无法安全剔除其余函数 - 改用 具名导入：
import { debounce } from 'lodash-es'或更细粒度的import debounce from 'lodash-es/debounce' - 第三方库优先选 ESM 原生版本：用 lodash-es 替 lodash，用 date-fns 替 moment，用 clsx 替 classnames
三、清副作用：package.json 中 sideEffects 是关键开关
Webpack 默认对有副作用的模块“不敢动”，哪怕只用了一个函数，也会保留整个文件：
- 若项目无全局样式注入、无 polyfill 注册、无 window 属性修改，直接设 "sideEffects": false（写在根目录 package.json）
- 若有真实副作用，必须显式列出，例如："sideEffects": ["./src/polyfill.js", "./styles/index.css"]
- 切勿在工具模块顶部写
import './reset.css'或require('core-js/stable')——把副作用移到入口文件或组件内部
四、验构建配置：确保 Webpack 真正执行了标记与删除
Webpack 5+ 在 production 模式下默认开启基础 Tree Shaking，但需确认关键环节已激活：
- 显式设置 optimization.usedExports: true（标记未使用导出）
- 启用 optimization.concatenateModules: true（合并模块提升分析精度）
- TerserPlugin 中开启 compress.unused: true 和 dead_code: true（执行最终删除）
- 确认没有在配置中误设 module.exports = { optimization: { sideEffects: false } }——sideEffects 是 package.json 字段，不是 Webpack 配置项
不复杂但容易忽略细节。核心就三点：代码用 ES Module 写、导入按需写、副作用明确声明。每次改完，一定回到第一步——用 source-map-explorer 看结果。
