Tree Shaking 是打包阶段静态分析 ES Module 的 import/export，仅移除未被引用的具名导出；对 default export、CommonJS、动态语法及有副作用代码无效，需配合 ESM 格式与正确配置。
Tree Shaking 是什么，它真能自动删代码吗？
Tree Shaking 不是运行时机制，也不是智能 AI 删除逻辑，它只在打包阶段（如 Webpack、Rollup、Vite）静态分析 import / export 语句，把**未被引用的具名导出（named export）** 标记为可移除。它对 default export 或 CommonJS 式的 module.exports 基本无效，因为后者无法在不执行代码的前提下判断导出是否被使用。
关键前提是：模块必须是 ES Module（.js 文件中用 export 和 import），且打包工具开启相应优化（如 Webpack 的 mode: 'production' + optimization.usedExports: true）。
- 只识别“死导出”（dead exports），不处理“死代码”（如未调用的函数声明、无副作用的变量赋值）
- 遇到
eval()、with、try/catch等动态语法，整个模块会被标记为有副作用，跳过 shaking - 即使写了
export const unused = 123，只要没被任何import { unused }引用，它大概率会被剔除
为什么 import lodash 一个函数却打包了整个库？
因为主流 CDN 或 npm 上的 lodash 默认导出的是一个 CommonJS 包，其 index.js 内部用 module.exports = { debounce, throttle, ... } 组装对象 —— 打包工具无法静态确认你只用了其中某个属性，只能全量保留。
解决办法不是靠 Tree Shaking，而是改用支持 ESM 的子路径导入：
立即学习“Java免费学习笔记（深入）”；
import debounce from 'lodash/debounce';
// 或
import { debounce } from 'lodash-es';lodash-es 是官方维护的 ES Module 版本，每个函数单独导出，配合 import 语句才能被正确 shake；而 lodash/debounce 路径在 Webpack 5+ 中也能触发模块级 tree shaking（前提是该入口本身是 ESM）。
- 避免
import _ from 'lodash'—— 这会引入全部方法和依赖 - 检查
node_modules/lodash-es/package.json是否有"type": "module"或"exports"字段，确保工具识别为 ESM - Vite 默认启用
lodash-esshaking；Webpack 需确认已启用experiments.topLevelAwait和optimization.concatenateModules
哪些写法会让 Tree Shaking 失效？
看似无关的代码，可能让整个模块“变胖”。常见失效点集中在副作用（side effects）判定上：
- 模块顶层写了
console.log('init')、localStorage.setItem('flag', '1')—— 工具认为它有副作用，不敢删 -
export default class X { constructor() { this.x = 1; } }即使没被 new，也可能因潜在实例化行为被保留 - 导出对象字面量：
export const utils = { foo() {}, bar() {} }—— 整个utils对象无法被部分 shake - 使用了
/*#__PURE__*/注释但位置错误（必须紧贴函数调用前，如/*#__PURE__*/foo()）
若确定某模块无副作用，可在 package.json 中显式声明：
"sideEffects": false
或更精确地列出有副作用的文件："sideEffects": ["*.css", "src/init.js"]。
除了 Tree Shaking，还有哪些实际有效的体积压缩手段？
Tree Shaking 只解决“没用的导出”，真正减体积要组合多种策略：
- 启用
terser-webpack-plugin（Webpack）或默认压缩（Vite/Rollup）—— 删除空格、缩短变量名、折叠常量 - 配置
splitChunks抽离公共模块（如react、lodash-es），避免重复打包 - 用
dynamic import()实现路由/组件级懒加载，让 chunk 按需下载 - 检查
source-map是否误打包进生产产物（确保devtool: false或'source-map'仅用于本地） - 用
webpack-bundle-analyzer查看哪些模块占比异常高，再针对性处理（比如替换成更轻量的替代库）
最常被忽略的一点：node_modules 中的 devDependencies 如果意外打进生产包（比如误在 dependencies 里装了 @types/react），也会显著增大体积 —— 检查 package.json 的依赖分类是否合理。
