tree shaking 验证核心是确认未使用的命名导出是否真正从 bundle 中消失，需依赖 esm 静态分析与打包器死代码消除，并通过构建产物反向验证；须启用严格 esm、纯函数标记、可视化分析、显式重导出及外部最小消费场景测试。
Tree Shaking 在组件库发布前验证，核心是确认 未被实际使用的导出项（尤其是命名导出）是否真正从最终 bundle 中消失。它依赖 ES Module 静态结构 + 模块打包器（如 Webpack、Rollup、Vite）的死代码消除能力，不能仅靠“写了 export 就算可摇”，必须通过打包产物反向验证。
1. 确保构建配置启用严格 ESM 和纯函数标记
Tree Shaking 的前提是模块系统可静态分析。组件库源码必须使用 export / import（非 module.exports），且构建工具需禁用 CommonJS 转换：
- Rollup：默认支持 ESM；在
output.format = 'es'下生成原生 ES 模块，避免设为cjs或iife - Webpack：设置
experiments.topLevelAwait = true（可选），optimization.usedExports = true，并确保module.rules对.js文件不启用 Babel 的commonjs插件 - 所有导出函数/常量建议加
/*#__PURE__*/注释（尤其高阶函数或副作用不明显的工具函数），帮助打包器识别无副作用
2. 使用打包分析工具生成可视化报告
发布前运行一次「最小消费场景」打包，并生成模块依赖图，重点检查导出项是否残留：
-
Rollup +
rollup-plugin-visualizer：在构建脚本中加入插件，生成stats.html，打开后可搜索组件名或工具函数名，看其是否出现在最终 chunk 中 -
Webpack +
webpack-bundle-analyzer：添加stats: 'verbose'并运行webpack --profile --json > stats.json，再用 analyzer 加载分析 -
Vite（用于 demo 构建验证）：执行
vite build --report，生成report.html，查看各模块引入链和大小
关键操作：创建一个极简测试入口（如 test-treeshaking.js），只导入组件库的默认导出或某一个组件，然后观察其他未导入的命名导出（如 ButtonGroup、utils/debounce）是否完全不出现在分析报告的 modules 列表里。
3. 检查导出方式是否阻碍 Tree Shaking
以下写法会导致整块模块无法被摇掉，即使只用了其中一小部分：
-
export * from './utils.js'—— 改为显式重导出：export { debounce, throttle } from './utils.js' -
export const components = { Button, Input }—— 这种对象聚合导出会保留整个对象，应改为独立命名导出：export { Button, Input } -
export default { install, version, components }—— 默认导出对象也会阻碍摇，若需兼容 Vue 插件，可用具名导出 + 单独的install函数
验证方法：在分析报告中搜索该聚合对象名或其属性名，若存在且 size > 0，说明它未被摇掉。
4. 模拟用户侧消费，做「反向验证」
在外部新建一个最小 React/Vue 项目，只安装你的组件库（npm link 或 file:../path/to/lib），然后只写一行导入：
import { Button } from 'my-ui-lib'执行构建后，检查产物中是否包含 Dialog、Icon、utils/uuid 等未引用模块的代码片段。可配合 grep -r "Dialog" dist/ 或在 source map 中搜索关键标识符。
更进一步：用 acorn 或 estree-walker 写简单脚本，解析最终 bundle 的 AST，统计所有 import 声明和实际被调用的导出变量，对比源码 index.ts 中的全部 export 项，生成缺失/冗余报告。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
