我为什么把“依赖管理”从“能跑就行”变成了“上线前必查”

刚入行时，我对依赖的态度是：缺什么加什么，版本冲突了就 mvn dependency:tree 看看，随便排个版本，能编译通过就完事。甚至还有过更离谱的操作——为了快速验证一个工具类，直接把别人的 jar 包下载下来扔进 lib 目录，连 Maven 都没用。那时候觉得依赖就是个“工具箱”，拿来用就行，谁会去关心里面装了什么。

直到那次安全漏洞告警，把我从这种“天真”里拽了出来。

一、一次漏洞，让我看到了依赖的“冰山”

那天 DBA 没找我，运维没找我，倒是安全团队发了一封邮件：“你负责的服务使用了 fastjson 1.2.68，存在反序列化远程代码执行漏洞（CVE-2022-25845），请立即升级。”

我第一反应是：fastjson？我代码里没直接用啊。翻了一下 pom.xml，确实没有直接依赖。但跑 mvn dependency:tree，发现它藏在深处：

order-service
├── user-client (内部 SDK)
│   └── common-utils
│       └── fastjson:1.2.68

一个内部 SDK 间接引入了漏洞版本，而我对此一无所知。更可怕的是，这个服务是对外暴露的 API，任何能构造恶意 payload 的人，理论上都能在我服务器上执行任意代码。

那次我花了半天时间升级依赖、重新打包、回归测试、紧急发布。事后统计：我们 30 多个服务里，有 17 个存在这个漏洞，全靠安全团队扫出来的。如果漏洞被利用，后果不堪设想。

二、依赖不是“免费的”，它是有代价的

这次事件让我重新审视依赖管理。以前我觉得“引入一个库”的成本是 0——加一行 pom 配置而已。现在明白，每个依赖都带着三份隐性账单：

1. 安全账单

第三方库的任何漏洞，都是你系统的漏洞。你引入的库越多，攻击面越大。而且很多库你根本没在用它的全部功能——为了一个 StringUtils.isEmpty()，你引入了整个 commons-lang3（虽然这个相对安全），但有人为了一个 MD5 工具引入了整个 Guava。

2. 体积账单

我们一个微服务，代码本身不到 5MB，但打出来的 jar 包 87MB。为什么？依赖传递。Spring Boot 的 fat jar 里，BOOT-INF/lib 塞了 120 多个 jar。启动慢、内存占用高、容器镜像大，全是依赖膨胀的锅。

后来我做了一次瘦身：用 spring-boot-maven-plugin 的 layers 功能分析，把真正用到的依赖列出来，排除掉没用到的。最终 jar 从 87MB 降到 52MB，启动时间从 23 秒降到 14 秒。

3. 兼容性账单

最头疼的是版本冲突。有一次我升级了 spring-boot-starter-parent 的一个小版本，结果 jackson 版本跟着升了，而我们的一个内部序列化工具依赖旧版 jackson 的 API，启动直接报 NoSuchMethodError。这种问题编译时不会报错，运行时才炸，而且错误信息极其隐晦。

三、我现在怎么管依赖

1. 引入前先问三个问题

• 这个库解决什么问题？有没有更轻量的替代？
• 它活跃吗？最近一次更新是什么时候？Issue 有人处理吗？
• 它带了多少传递依赖？会不会引入冲突？

如果答案是“只是想要一个工具方法”，我宁可自己写 10 行代码，也不引入一个 2MB 的库。

2. 定期扫描漏洞

我们用 OWASP Dependency-Check 集成到 CI 里，每次构建自动扫依赖漏洞。高危漏洞直接阻断发布。每月还会跑一次 dependency-check:aggregate 生成完整报告，逐个排查。

3. 锁版本，不漂移

以前我们用 spring-boot-starter-parent 管理依赖版本，自己不指定。后来发现升级 parent 版本时，传递依赖版本会跟着变，可能引入不兼容。现在关键依赖全部显式指定版本号，用 dependencyManagement 统一管控。

4. 定期清理

每季度做一次依赖清理：跑 mvn dependency:analyze，看看哪些依赖声明了但没用到（unused declared），哪些用到了但没声明（used undeclared）。前者直接删，后者补上声明。保持 pom.xml 干净，也是减少风险。

四、一个意外收获：依赖管理倒逼架构优化

有一次清理依赖时，我发现一个服务间接依赖了 5 个不同的 HTTP 客户端库：OkHttp、Apache HttpClient、RestTemplate、WebClient、HttpURLConnection。原因是不同内部 SDK 各用各的。我借机推动统一了 HTTP 客户端，封装了一个 HttpService 供所有 SDK 使用。结果依赖少了、连接池统一管理了、超时配置一致了，连排查网络问题都容易了。

五、一个心态的转变

以前我觉得依赖管理是“体力活”，现在觉得是安全底线。你写的代码你可以控制质量，但引入的第三方库你控制不了——它的 Bug、它的漏洞、它的行为变更，都是你系统的一部分。你不为它写代码，但你要为它的问题负责。

如果你现在的 pom.xml 或 package.json 已经很久没清理过了，不妨今晚跑一下依赖分析。看看里面有多少是你不知道的库、有多少版本已经过时、有多少存在已知漏洞。不用一步到位全部升级，但至少知道自己的“家底”里藏着什么。毕竟，安全漏洞不会提前通知你，它只会在被利用的那一刻，让你措手不及。