tree shaking 本身不保证轻量化，关键在于主动配合其机制：统一使用 es 模块语法（禁用 babel 转译 commonjs）、细粒度按需导出/引入、显式声明 sideeffects、验证产物中无 unused harmony export 等。
Tree Shaking 本身不“保证”轻量化，它只在满足前提条件时自动移除未使用的导出代码。真正让业务代码轻量化的关键，是主动配合 Tree Shaking 的机制来组织和编写代码。
用 ES 模块语法，杜绝 CommonJS
确保所有业务模块都使用 import/export，而不是 require/module.exports。CommonJS 是运行时动态加载，打包工具无法静态分析依赖关系，Tree Shaking 对其完全无效。
- 入口文件、页面逻辑、工具函数、状态管理模块——全部统一为 ES 模块写法
- 如果用了 Babel，必须设置
modules: false（禁用转译成 CommonJS），否则 import 会被编译掉，失去静态可分析性 - 第三方库优先选 ESM 版本，比如用
lodash-es替代lodash，用date-fns替代moment
按需导出 + 按需引入
避免“一锅端”式导出和导入。一个模块里导出十几个函数，但业务只用其中一个，整块仍可能被保留。
- 导出粒度要细：用
export function formatTime()、export function parseDate()，而不是export default { formatTime, parseDate, ... } - 引入也要精准：写
import { formatTime } from './utils'，而不是import utils from './utils'或import * as utils from './utils' - 组件也一样：Vue/React 中避免
import MyLib from 'my-lib'，改用import { Button, Input } from 'my-lib'（前提是该库支持 ESM）
显式声明无副作用
即使代码没被引用，只要打包工具认为它有“副作用”，就会保守保留。业务模块中常见副作用包括：顶层执行 API 请求、监听全局事件、修改 window 属性、注入样式等。
- 在
package.json中添加"sideEffects": false，表示所有模块默认无副作用 - 若某些文件确实有副作用（如
src/main.js初始化逻辑、src/styles/index.css），就用数组精确列出："sideEffects": ["./src/main.js", "./src/styles/*.css"] - 日志、埋点等纯上报行为，应封装成独立模块，并确保内部不触发网络请求或改变状态；再配合
process.env.NODE_ENV === 'production'编译期剔除，比依赖 Tree Shaking 更可靠
验证是否真正生效
别假设它起了作用，必须检查产物。
- 构建后打开 dist 目录下的 bundle 文件，搜索
unused harmony export—— 若存在，说明 Webpack 已标记但未删，通常是因为没启用 Terser 压缩 - 用
webpack-bundle-analyzer或source-map-explorer可视化分析，看目标函数是否出现在最终模块图中 - 故意在入口加一行
import { unusedHelper } from './helpers'，再构建对比体积变化：没变，说明 Tree Shaking 正常工作；体积增大了，说明它被打了进去——得回头查写法或配置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
