检测第三方库是否支持 tree shaking，核心是验证其是否满足两个硬性前提：使用 es module 语法导出 + 显式声明 sideeffects 信息；需检查 package.json 的 "type": "module" 或 "exports" 字段指向 esm 文件，并确认 dist 源码仅含 export 语句、无副作用及模块粒度合理，最后通过 webpack-bundle-analyzer 实测验证。
检测第三方库是否支持 Tree Shaking，核心是验证它是否满足两个硬性前提：使用 ES Module 语法导出 + 显式声明 sideEffects 信息。不能只看“有没有 import”，而要看构建工具能否真正静态分析并安全剔除未用代码。
看 package.json 是否声明了 "type": "module" 或导出字段
打开库的 package.json，重点检查以下几项：
- "type": "module"：明确标识整个包以 ESM 方式解析（最直接信号）
-
"exports" 字段（推荐）：如
"exports": { ".": { "import": "./dist/index.js" } }，且指向的是 ESM 格式文件（通常含.mjs或type: module的.js） -
"main" 和 "module" 字段（旧式）：若存在
"module": "./es/index.js"，且该路径下是纯export语法，也属支持；但"main"指向cjs文件不构成障碍，只要实际被引用的是 ESM 入口
查源码或 dist 文件是否为纯 ESM 导出
进入库的 node_modules/xxx，打开其主入口（如 dist/index.js 或 es/index.js），确认：
- 只有
export const xxx、export function xxx、export { a, b }等命名导出，没有module.exports = {...}或export default {...}包裹全部功能 - 没有在顶层执行副作用代码（如直接调用
document.body.appendChild()、localStorage.setItem()、require('xxx')） - 每个功能分散在独立小文件中（如
debounce.js、throttle.js），而非全量打包进一个大文件
用工具实测打包结果
最可靠的方式是放进真实项目里跑一次构建分析：
- 用
webpack-bundle-analyzer构建后打开可视化报告，搜索该库名 —— 若只出现你import的个别函数（如debounce），没出现其他未引入方法，说明摇树生效 - 对比体积差异：比如
lodash（CommonJS）vslodash-es（ESM），后者 gzipped 体积常小 60%+，就是摇树起效的直观证据 - 访问 npm.devtool.tech，输入包名（如
date-fns），它会自动检测并标注 “✅ Supports tree-shaking” 或 “❌ Not tree-shakable”
注意常见误导信号
有些现象看似支持，实则不可靠：
- “能写
import { xxx } from 'yyy'” 不等于支持 —— 如果底层仍是export default {xxx: ..., yyy: ...}，Webpack 无法拆解对象属性 - 包里有
sideEffects: false，但内部有 CSS 注入或 polyfill，会导致功能异常，属于错误声明 - 文档写“支持 ESM”，但发布的
exports指向的是 Babel 编译后的commonjs文件，静态分析仍失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
