核心是用 webpack-bundle-analyzer 可视化模块构成，结合 usedExports 配置与命名导入导出，定位未使用代码并验证第三方库的 ESM 支持情况。

要分析打包产物中的冗余代码，核心是“看见”哪些代码被引入却未被使用——Tree Shaking 本身不直接展示冗余项，而是依赖工具链帮你可视化、定位和验证。关键不在猜测，而在可观察的证据链。

用 webpack-bundle-analyzer 查看模块构成

这是最直观、最常用的方式。它把最终 bundle 渲染成交互式层级图，按体积排序，一眼识别“大而空”的模块：

• 安装：npm install --save-dev webpack-bundle-analyzer
• 在 webpack 配置中添加插件（生产构建后自动打开分析页面）：
  new BundleAnalyzerPlugin()
• 重点关注：只导出但未被 import 的模块（如某个 utils.js 占 120KB，但项目里只用了其中 1 个函数）、整包引入的第三方库（如 import _ from 'lodash' 而非 import debounce from 'lodash/debounce'）

检查源码导出与实际引用是否匹配

Tree Shaking 生效的前提是 ES 模块的静态可分析性。你需要人工核对两处：

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 目标模块是否用 export 命名导出（如 export const foo = ... 或 export function bar() {...}），而非 default 导出或 CommonJS 方式
• 业务代码中是否用 命名导入（import { foo } from './utils'），而不是 namespace 导入（import * as utils from './utils'）或默认导入（import utils from './utils'）
• 例如：若 math.js 同时导出 add 和 multiply，但你只写了 import { add } from './math'，那么 multiply 就属于潜在冗余，analyzer 中该模块的“未使用部分”会变灰或标为“unused exports”

启用 usedExports + Terser 的详细日志

Webpack 不会默认告诉你“哪行被摇掉了”，但可通过配置让压缩阶段输出标记信息：

立即学习“Java免费学习笔记（深入）”；

• 在 webpack.config.js 中开启 usedExports：
  optimization: { usedExports: true }
• 配合 TerserPlugin 开启 compress.warnings: true，构建时会打印类似：
  Dropping unused function unusedHelper [./src/utils.js:15:0]
• 注意：这类提示仅在 production 模式下生效，且要求代码未被 babel 转译成 CommonJS（检查 .babelrc 是否保留 export/import）

验证第三方库是否支持 Tree Shaking

很多冗余来自 npm 包本身。不能只看你自己写的代码：

• 查看库的 package.json，确认是否存在 "module": "dist/esm/index.js" 字段（ESM 入口）
• 优先选用带 -es 后缀的版本，如 lodash-es、date-fns（原生 ESM，开箱支持摇树）
• 避免使用仅提供 CommonJS 的库（如老版本 moment、axios），它们的导出无法被静态分析，整个文件会被保留