Tree Shaking 生效的关键是代码可静态分析：剥离顶层副作用、分拆具名导出、避免动态导入，并通过构建产物验证。需将初始化逻辑封装为函数，设 sideEffects 配置，用可视化工具确认未引用代码被移除。
在复杂业务逻辑中保持代码纯净，是 Tree Shaking 能真正生效的关键前提。业务越重，副作用、动态行为、隐式依赖就越容易混入，导致本该被摇掉的代码被整块保留。核心不是“写得少”，而是“写得可分析”。
把副作用从模块顶层彻底剥离
哪怕一个 console.log、一次全局变量赋值、一段事件监听绑定，只要写在模块最外层（非函数体内），Rollup 或 Webpack 就会认为该模块有副作用，进而保守保留整个文件——哪怕你只 import 了其中一个小工具函数。
- ❌ 错误写法：src/utils/api.js 顶部直接调用
initApiInterceptor()或修改window.API_BASE - ✅ 正确做法：将所有初始化、注册、副作用逻辑封装进函数，仅导出纯函数或配置对象；入口处或应用启动时再显式调用
- 补充：在 package.json 中设
"sideEffects": false，或精确列出有副作用的文件，如"sideEffects": ["./src/polyfills.js", "./src/theme/index.css"]
拆分逻辑单元，避免“大模块+默认导出”陷阱
复杂业务常把权限校验、状态同步、日志上报等能力塞进一个 BusinessService.js 并默认导出为对象。这种写法会让 Tree Shaking 失效——打包器无法判断你到底用了其中哪几个方法。
- ❌ 错误结构：
export default { checkAuth, syncUser, logEvent }，使用者import Service from './BusinessService'; Service.checkAuth(); - ✅ 推荐结构：每个能力单独具名导出，
export function checkAuth() { ... }，export function syncUser() { ... }；入口按需导入：import { checkAuth } from './business/auth.js' - 进阶技巧：用“巴氏分发”方式组织入口文件，
export { checkAuth } from './auth/check.js'; export { syncUser } from './user/sync.js';
谨慎使用动态行为和运行时分支
Tree Shaking 是静态分析过程，所有依赖关系必须在构建期确定。一旦出现动态路径、条件导入、计算属性导出，分析链就中断，相关模块会被整体保留。
- ❌ 避免：
import(`./features/${featureName}.js`)、export const actions = { [type]: handler }、if (IS_DEV) import('./debug-tools') - ✅ 替代方案：对有限枚举场景，改用静态多路导入 + 对象映射，例如
import { featureA, featureB } from './features'; const map = { a: featureA, b: featureB }; - 提示：若必须支持插件化加载，可将动态部分抽离为独立 chunk，并明确告知构建工具不参与主包 Tree Shaking（如 Rollup 的
preserveModules: true）
用构建产物反向验证，不靠感觉靠证据
再严谨的写法，也需实证。复杂项目中，某段逻辑看似没被引用，却因间接依赖、类型定义、或 Babel 插件注入而意外保留。
- 检查最终 bundle：构建后搜索目标函数名（如
calculateOrderTotal），确认未出现；若出现，顺藤摸瓜查谁 import 了它 - 启用可视化工具：Rollup 配
rollup-plugin-visualizer，Webpack 用webpack-bundle-analyzer，看模块是否真的“悬空” - 主动注入测试导出：在 utils 中加一个明显无用函数
export function __SHOULD_BE_REMOVED() {}，引入它再构建——如果体积没变，说明 Tree Shaking 已生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
