Tree Shaking 是需代码、配置、依赖协同的轻量机制，依赖ESM、无副作用声明、精准导入及构建验证。混用CommonJS、未设sideEffects、全量导入或顶层副作用均导致失效。
Tree Shaking 不是“开了就自动瘦”的开关，而是一套需要代码、配置、依赖三方协同的轻量保障机制。它生效的前提非常明确：构建工具必须能静态确认某段代码“绝对没被用过”，且移除它不会改变程序行为。只要任一环节打破这个确定性，未使用代码就会原样保留——哪怕你只 import 了一个函数，也可能打包进整个库。
确保模块系统完全基于 ESM
Tree Shaking 只对 ES 模块（import/export）有效。CommonJS（require/module.exports）是运行时动态加载，无法静态分析，一旦混入，整条依赖链就“失明”了。
- 项目内所有自写模块必须用
export和import，禁用require - 第三方库优先选提供原生 ESM 的版本，例如用
lodash-es替代lodash，用date-fns替代moment - Babel 编译时关闭模块转换：
{"modules": false}，避免把 ES 模块转成 CommonJS - 发布自己的包时，在
package.json中通过"type": "module"或"exports"字段明确暴露 ESM 入口
显式声明无副作用，解除打包器的保守顾虑
即使某个模块没被引用，如果打包工具不能 100% 确定它没执行全局操作（比如给 Array.prototype 加方法、往 window 挂变量、注入 CSS），就会为安全起见保留全部代码——这是 Tree Shaking 失效最常见原因。
- 在库或工具包的
package.json中设置"sideEffects": false，表示所有 JS/TS 文件纯正无害 - 若存在真实副作用（如全局样式、polyfill），只列出具体路径：
"sideEffects": ["./styles/index.css", "./polyfill.js"] - 业务项目也建议配
sideEffects: false，再按需放开 CSS 等资源文件
杜绝全量导入，让静态分析有迹可循
像 import _ from 'lodash-es' 这种写法，等于告诉打包器：“我可能用到里面任何东西”，Tree Shaking 就无从下手。
立即学习“Java免费学习笔记（深入）”；
- 始终使用命名导入：
import { debounce, throttle } from 'lodash-es' - 组件库启用按需加载：Ant Design 配
babel-plugin-import，Element Plus 直接用el-button的 ESM 路径 - 避免在模块顶层执行逻辑（如直接调 API、修改原型），这类代码会被视为强制保留的副作用
验证与闭环：别信“应该生效”，要看见“确实删了”
不验证的 Tree Shaking 等于没做。体积数字不会说谎，但得用对工具才能看清真相。
- 生产构建后，用
rollup-plugin-visualizer（Rollup/Vite）或webpack-bundle-analyzer查看模块构成，确认大库是否只剩几 KB - 搜索产物中是否存在未使用函数名或明显冗余代码（如整个
lodash/_baseClamp.js） - 检查 source map，定位某段代码为何没被摇掉——常因间接引用、条件导出、
eval或 try-catch 干扰静态分析
