开源项目的依赖精简如何做

本文目录导读：

1. 依赖分析：先诊断，再开刀
2. 核心精简策略
3. 实操里程碑（可量化的精简目标）
4. 必须避的坑（严肃警告）
5. 命令行速查（复制即用）
6. 长期维护建议

开源项目的依赖精简是一个系统性工程,核心目标是减少构建时间、降低安全风险、缩小产物体积、提升可维护性，以下是实操指南，从分析、清理、验证三个维度展开。

依赖分析：先诊断，再开刀

在动手之前,必须搞清楚当前依赖的真实使用情况，推荐使用自动化工具：

核心精简策略

移除“死”依赖（最直接）

• unused dependency：代码中已不再 import，但 package.json 或 pom.xml 中仍有声明。
• devDependencies 误放：把构建、测试工具（如 webpack, jest, eslint）放到了 dependencies 里。
• 操作：运行 depcheck 或 npx unimported，得到列表后逐个确认删除。

减少“间接依赖”（Tree Shaking）

• 问题：引用了 lodash、moment.js 等大库，但只用了其中 1-2 个函数。
• 做法：
  • 使用 Tree-Shaking 友好写法：import { isArray } from 'lodash-es'（而非 import _ from 'lodash'）。
  • 替代方案：
    • moment.js -> dayjs / date-fns（体积减少 90%）。
    • jQuery -> 原生 DOM API。
    • 大型 UI 库（如 antd） -> 按需加载（使用 babel-plugin-import 或 unplugin-auto-import）。

合并与整理重复依赖

• 问题：多个子依赖依赖了同一个库的不同版本（A 依赖 lodash@4.17，B 依赖 lodash@4.15），导致打包两份。
• 做法：
  • NPM：运行 npm ls <package> 查看冲突，使用 npm dedupe 或 overrides（package.json 中的 resolutions 字段）强制统一版本。
  • Maven：使用 <dependencyManagement> 强制版本，或用 <exclusions> 排除冗余传递依赖。

避免“全量引入”的依赖

• 例子：axios（HTTP 客户端）实际上打包了 form-data、follow-redirects 等，如果你只发 GET 请求，可以考虑用 ky 或原生 fetch。
• 做法：分析核心功能的实际需求，选择更轻量的库（如 micromatch 替代 minimatch，cbor 替代 bson）。

利用构建工具的能力

• Webpack/Vite：启用 sideEffects: false（package.json 中），让构建工具自动摇掉模块中未引用的导出。
• Rollup：使用 @rollup/plugin-terser 或 @rollup/plugin-commonjs 对 CJS 模块进行 Tree Shaking。
• Babel：配置 useBuiltIns: 'usage' 按需引入 polyfill，而非全量引入 core-js。

实操里程碑（可量化的精简目标）

一个中等规模的开源项目（前端/后端均可参考），经过上述步骤后，理论上的优化效果：

必须避的坑（严肃警告）

1. 不要盲目相信工具输出：depcheck 等工具可能漏检动态引入（如 require(path) 或 import() 字符串拼接）。对所有“可删除”的依赖，必须手动搜索代码中所有引用（包括配置文件、脚本、如 .babelrc 引用了 babel-plugin-xxx）。
2. 小心“隐式提供”的依赖：比如多个包都依赖 typescript，你只删除了 typescript 在顶级声明，但子包仍依赖它，运行 npm ls 确认。
3. 测试覆盖：精简后必须跑通完整的 CI 流水线（单元测试、集成测试、E2E 测试），尤其注意 CSS 渲染、SSR、Edge 环境等特殊场景。
4. 渐进式精简：不要一次删除 50 个依赖，最好 分批 + 逐个版本提交，这样出了问题好二分排查（git bisect）。

命令行速查（复制即用）

# Node.js
npx depcheck                   # 检测未使用依赖
npm ls --depth=0 | grep -v dedupe # 查看顶层依赖
npm dedupe                     # 去重
npm prune   [production]       # 移除 node_modules 中未在 package.json 声明的包
# Java
mvn dependency:tree    -DoutputFile=deps.txt
mvn dependency:analyze -DignoreNonCompile=true
mvn versions:display-dependency-updates   # 版本大升级
# Python
pipdeptree --reverse            # 查看反向依赖（谁依赖于谁）
pip install pyremove_deps       # 或手动逐个检查

长期维护建议

1. 设定依赖治理规则：PR 中新增依赖必须经过 Review，并填写“为什么不能使用原生 API/轻量库”。
2. 使用自动化工具监控：
   • Dependabot / Renovate：自动提交依赖版本更新 PR，避免版本碎片。
   • BundlePhobia（前端）：新增依赖前查看其打包体积。
   • Fossa / Snyk：扫描许可证和安全漏洞，倒逼精简。
3. 定期清理（每季度一次）：运行 npm outdated 和 depcheck，形成“依赖健康报告”。

你甚至可以问自己一个问题：这个依赖真的需要吗？ 很多开源项目过度依赖第三方库，实际上用 50 行原生代码就能实现（is-empty, clone-deep 等工具函数）。极度精简 = 极致性能 + 最小攻击面，动手试试吧！