Tree Shaking 的高级能力源于四步闭环：理解约束、写对结构、配准链路、验证效果；必须使用 ES Module、显式导出、精准声明副作用，并通过产物分析验证。
Tree Shaking 不是靠“学模式”练出来的，而是靠理解约束条件、写对代码结构、配准构建链路、验证实际效果这四步闭环形成的工程直觉。所谓“高级编程模式”，本质是把基础规则内化为编码习惯后的自然表达。
用 ES Module 写模块，不是“支持”，而是唯一路径
CommonJS（require/module.exports）在任何构建工具中都无法被 Tree Shaking 分析——它运行时才决定加载什么，构建器根本看不到依赖关系。所以：
- 所有自定义工具函数、业务模块、配置文件，必须用
export function xxx或export const xxx显式导出，禁用module.exports = {...} - 入口文件、组件、hooks 等，统一用
import { a, b } from './utils'，避免import utils from './utils'（默认导出会包裹整个对象） - 如果历史代码混用 CommonJS，别强行“转语法”，优先重构模块边界：把老模块封装成 ESM wrapper，例如新建
utils-esm.js，里面import oldUtils from './old-utils.cjs'; export const { debounce } = oldUtils;
第三方库必须选 ESM 友好版本
lodash 和 lodash-es 是两个包，不是同一包的两个版本。前者经 Babel 处理后几乎全转为 CommonJS，后者从源码就是纯 ESM 结构。同理：
- 用
date-fns替代moment（后者无 ESM 支持） - 用
@ant-design/icons-react/es路径导入图标，而不是@ant-design/icons-react入口 - 查库是否支持 ESM：看它的
package.json是否有"module": "dist/index.esm.js"或"exports": { ".": { "import": "./dist/index.mjs" } }
副作用声明要精确到文件粒度
"sideEffects": false 是最省事的写法，但极容易误删关键逻辑。真正高级的做法是“最小化声明”：
- 只把真实执行副作用的文件列出来：
"sideEffects": ["./src/polyfill.js", "./src/theme.css", "./src/global.css"] - CSS 文件必须显式列出，否则
import './Button.css'可能被摇掉（即使你用了这个组件） - 避免在工具函数模块顶部写
import './reset.css'—— 把样式引入移到 App 或 Layout 组件里，让副作用集中可控 - 全局 polyfill 如
core-js/stable，也应单独建polyfill.js并加入sideEffects数组，不要塞进utils/index.js
验证不能靠猜，要靠产物反推
配置写完 ≠ 效果生效。真正的高级能力体现在你能快速定位为什么某段代码没被摇掉：
- 用
source-map-explorer dist/main.js查看 lodash-es 中哪些函数被打进了 bundle（图形化识别冗余） - 开启 Webpack 的
stats: 'verbose'，搜索unused harmony export，确认未使用导出是否被标记 - 临时加一行
import { someUnusedHelper } from './helpers';，构建前后对比体积变化 —— 如果体积不变，说明该模块已成功被摇；如果变大了，说明它原本就没被摇（可能有副作用或被 namespace 导入间接引用） - 用 VS Code 插件 “Import Cost” 实时查看某行 import 预估引入体积，提前规避高风险写法
不复杂但容易忽略：Tree Shaking 的高级感，来自对“静态可分析性”的敬畏——每写一个 import，都清楚它在依赖图里牵动了哪条线；每加一个 export，都确认它是否真会被消费。它不是炫技，而是让代码诚实可预测。
