3、依赖图谱分析：构建依赖树、识别循环依赖、分析传递依赖、可视化工具介绍
依赖图谱分析，说白了就是给你的项目做一次「CT扫描」。
我接手过不少遗留系统，最头疼的不是代码写得烂，而是根本搞不清谁依赖谁。你改了一个底层库，结果线上炸了一片，没人说得清为什么。嗯，这就是依赖图谱没搞清楚的后果。
3.1 构建依赖树：从根节点开始梳理
依赖树，就是把你的项目当成一棵大树。根节点是你的主项目，叶子节点是那些最底层的第三方包。
我个人习惯用 mvn dependency:tree 或者 npm ls 来快速生成。举个例子：
# Maven 项目
mvn dependency:tree -DoutputFile=deps.txt
# npm 项目
npm ls --all > deps.txt
输出结果长这样：
com.mycompany:my-app:jar:1.0
+- org.springframework:spring-core:jar:5.3.20
| +- org.springframework:spring-jcl:jar:5.3.20
| \- commons-logging:commons-logging:jar:1.2
+- com.google.guava:guava:jar:31.1-jre
| +- com.google.guava:failureaccess:jar:1.0.1
| \- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava
你看，缩进就代表了层级关系。每一层缩进，就是一个依赖深度。
3.2 识别循环依赖：最隐蔽的定时炸弹
循环依赖是什么？就是 A 依赖 B，B 依赖 C，C 又依赖 A。形成了一个死循环。
为什么会这样？说白了就是模块划分没想清楚。你想想看，两个模块互相调用，那它们到底谁该归谁管？
识别方法其实很简单：
- 编译期报错：Java 里如果出现循环依赖，编译直接报错。这是好事，早发现早解决。
- 运行时死循环：Python、JavaScript 这类动态语言，循环依赖可能编译不报错，但一运行就栈溢出。
- 工具扫描：用
jdeps或者dependency-check这类工具。
我给你们看个真实案例。之前有个项目，A 模块引用了 B 模块的工具类，B 模块又引用了 A 模块的配置类。看起来没什么，但一启动就报 StackOverflowError。查了半天，发现是初始化时互相调用了对方的静态方法。
3.3 分析传递依赖：蝴蝶效应的源头
传递依赖，就是「你依赖的包，它自己也有依赖」。这些间接引入的依赖，往往是最容易出问题的。
举个例子：
你的项目 -> 依赖了 Log4j 2.14.0
Log4j 2.14.0 -> 依赖了 JNDI 查找功能
JNDI 查找功能 -> 存在 Log4Shell 漏洞
你看，你明明只写了一个日志调用，结果引入了一个高危漏洞。这就是传递依赖的威力。
分析传递依赖，我一般关注三点：
- 版本冲突：同一个包被不同模块依赖了不同版本，最终哪个生效？
- 漏洞传播：底层库有 CVE，你的项目是否受影响？
- 冗余依赖：有些传递依赖根本用不上，白白增加包体积。
| 场景 | 工具 | 命令示例 |
|---|---|---|
| Java 传递依赖分析 | Maven Dependency Plugin | mvn dependency:tree -Dverbose |
| npm 传递依赖分析 | npm ls | npm ls --depth=5 |
| Python 传递依赖分析 | pipdeptree | pipdeptree --warn silence |
3.4 可视化工具介绍：让依赖关系一目了然
光看命令行输出，说实话挺累的。尤其是项目大了以后，依赖树能打印出几千行。这时候就需要可视化工具了。
我常用的几款：
- Graphviz：老牌工具，能把依赖关系转成 DOT 语言，然后生成图片。
- Dependabot：GitHub 自带，自动扫描依赖并生成可视化报告。
- Snyk：商业工具，但免费版也够用，能直接展示依赖路径和漏洞。
- DepGraph：IntelliJ IDEA 插件，直接在 IDE 里看依赖图。
下面是我用 SVG 画的一张依赖图谱分析流程图，帮你理清整个分析思路：
这张图其实就概括了依赖图谱分析的完整流程。先构建树，再找循环，然后分析传递依赖，最后可视化呈现。每一步都不能少。
嗯，依赖图谱分析就聊到这儿。记住一句话：依赖关系不是写出来的，是长出来的。你不主动管理，它就会野蛮生长，最后变成一团乱麻。