模块化是识别冗余第三方模块的前提，需结合esm语法、构建工具（webpack/vite）静态分析、命名导入、package.json的"module"字段声明，并通过stats.json比对源码定位死代码；同时要检查重复依赖版本、配置sideeffects、避免顶层副作用以保障tree shaking有效。
模块化本身不直接检测冗余，但它是构建分析能识别并剔除未使用第三方模块的前提。关键在于结合 ESM 语法、构建工具能力与工程配置，形成可验证的优化闭环。
确认第三方模块是否真正被引用
构建工具（如 Webpack、Vite）只能基于静态 import 语句推断依赖关系。如果一个模块被 import 了却从未调用其导出内容，它仍可能保留在打包结果中——尤其当该模块有副作用或使用 CommonJS 导入时。
- 优先用命名导入：import { debounce } from 'lodash-es'，而非 import _ from 'lodash'
- 避免路径模糊写法，例如 import utils from 'my-lib/utils'（若该路径不是 ESM 入口，Tree Shaking 失效）
- 检查库的 package.json 是否声明 "module": "es/index.js"，否则构建工具无法静态分析
用构建产物反向验证模块是否冗余
生成 stats.json 并比对源码文件，是最直接的冗余判定方式：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 运行构建命令并输出 stats：Webpack 用 webpack --json > stats.json；Vite 用 vite build --report
- 提取所有被实际打包进 chunk 的模块路径（过滤掉 node_modules）
- 用脚本扫描 src/ 下全部文件，找出未出现在 stats 中的 JS 文件——这些就是未被任何模块引用的“死代码”
- 特别关注那些只 import 第三方库但没调用任何 API 的文件，它们往往导致整包残留
识别和清理重复或冲突的第三方版本
多个版本的同一依赖（如 axios@0.21 和 axios@1.6）会同时被打包，显著增大体积。
- 执行 yarn list axios 或 npm ls axios 查看嵌套层级与版本分布
- 安装 duplicate-package-checker-webpack-plugin，构建时自动报出重复包
- 配合 webpack-bundle-analyzer 可视化查看哪些 chunk 引入了相同包的不同副本
- 统一版本后，运行 yarn dedupe（Yarn 3+）或 npm-force-resolutions 锁定主版本
处理副作用与样式等隐性依赖
有些模块看似只导出函数，实则在顶层执行了 DOM 操作、注入 CSS 或修改全局对象——这类“副作用”会让构建工具不敢删除它，哪怕你只用了其中一行代码。
- 项目根目录 package.json 中设置 "sideEffects": false，再显式列出真实副作用文件："*.css", "./src/init.js"
- 避免在模块顶层写 document.body.appendChild()、console.log() 或原型扩展
- 对 UI 组件库（如 Element Plus），启用 unplugin-vue-components 自动按需引入，避免模板中写了
却没 import 导致全量加载
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
