tree shaking 需代码写法、构建配置与依赖管理协同：必须使用 es module（import/export），禁用 commonjs；第三方库选 esm 版本（如 lodash-es）；具名导入而非 namespace 导入；合理配置 sideeffects；并用工具验证效果。
Tree Shaking 不是开关一开就自动生效的魔法，它需要代码写法、构建配置和依赖管理三者协同。Webpack 5 默认在 production 模式下启用基础 Tree Shaking，但真正发挥效果，得靠你主动配合。
确保模块系统是 ES Module
这是前提中的前提。Tree Shaking 只对 import/export 有效，对 require/module.exports 完全无效。
- 检查项目中所有自定义模块是否都用 ES 语法导出：避免在工具函数文件里混用
module.exports = {...} - 第三方库要选 ESM 版本：比如用
lodash-es替代lodash，用date-fns替代moment - 如果必须用 CommonJS 库，可通过插件转换（如
vite-plugin-commonjs或 Webpack 的babel-plugin-transform-commonjs），但效果不如原生 ESM 稳定
用对 import 方式，别让“摇树”失效
导入写法直接决定 Webpack 能不能识别哪些导出被真正使用。
- 禁用命名空间导入：
import * as utils from './utils'—— 这会让整个模块被视为“被引用”，无法摇掉未用函数 - 优先具名导入：
import { debounce, throttle } from 'lodash-es'—— Webpack 可精准标记其余函数为未使用 - 避免默认导入全量包：
import _ from 'lodash'改为按路径导入：import debounce from 'lodash-es/debounce'
声明副作用，防止误删关键代码
Webpack 发现某个模块有副作用（比如注入 CSS、注册全局 polyfill、修改 window），就会保守保留整个文件，哪怕只用了其中一两个函数。
- 在项目根目录
package.json中添加："sideEffects": false（表示所有模块无副作用） - 如果有真实副作用，明确列出文件：
"sideEffects": ["./src/polyfill.js", "./styles/index.css"] - 避免在模块顶层执行副作用逻辑：把
import './reset.css'移到组件内部或入口文件，而不是放在工具函数模块顶部
验证与持续优化
别只看配置，要确认结果。
- 用
source-map-explorer分析打包产物，查清lodash-es里到底打了哪些函数 - 开启 Webpack 的
stats: 'verbose'，搜索unused harmony export看哪些导出被标记为未使用 - 升级到 Webpack 5+，并确保
optimization.usedExports: true（虽然 production 模式默认开启，但显式声明更稳妥）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
