引一个库只要一行坐标，扔掉它要动整条链路。两年后真正难受的，不是这个库不好用，而是它不再发版、它的传递依赖卡住了 JDK 升级、它的 API 在某个次要版本里悄悄改了语义。
组件选型的本质不是"哪个库功能强"，而是"我愿意为它承担多久的维护责任"。这篇给判断依据和代价结构。
1. 五个维度与它们的观测方式
功能对比最容易做也最不重要；决定库能否留下的是下面五件事，每件都有可观测指标。
| 维度 | 观测什么 | 常见误判 |
|---|---|---|
| 活跃度 | issue 首次响应、近一年发版节奏、破坏性变更是否公告 | 只看 star 与提交总数 |
| 依赖树 | 传递依赖数量、是否带进重复门面 | 只看直接依赖名 |
| API 稳定性 | 次要版本是否出现行为变化、废弃是否提前公告 | 把"能编译"当成"兼容" |
| 可替换性 | 业务代码直接 import 的处数、有无端口接口 | 以为"以后重构就行" |
| 团队熟悉度 | 出问题时谁能读源码、谁能提 patch | 把"我用过"当成"团队会用" |
活跃度里最该看的是 issue 响应，不是提交频率：每季度发版但有人回 issue 的库，通常比每天提交、issue 堆两千的更可靠。
2. 依赖树的隐性成本
引入一个库，引入的是它的整棵依赖树。这棵树在三个地方收费：冲突、体积、漏洞传导。
| 成本 | 表现 | 观测方式 |
|---|---|---|
| 传递依赖冲突 | 同一库出现两个版本，调解结果不是你想要的 | dependency:tree -Dverbose |
| 包体积 | 镜像变大、启动扫描变慢 | 构建产物对比、类数统计 |
| CVE 传导 | 没用到的子依赖报漏洞，仍要跟着升级 | 依赖扫描报告 |
mvn -q dependency:tree -Dverbose -Dincludes=com.example # 看冲突与调解
mvn -q dependency:analyze # 声明了但没用到（反射会误报）
<dependency>
<groupId>com.example</groupId><artifactId>widget</artifactId>
<version>${widget.version}</version>
<exclusions>
<!-- 排除必须有理由：什么冲突、何时可撤 -->
<exclusion><groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId></exclusion>
</exclusions>
</dependency>
3. "标准库能做就别引"的判据
标准库的价值不在功能多，而在它跟着 JDK 升级，没有额外维护合同。判据是三件事：功能是否已在标准库、缺口是否只是"写起来麻烦"、这个麻烦是否值得换一个长期依赖。
| 需求 | 标准库方案 | 何时才值得引库 |
|---|---|---|
| HTTP 调用 | java.net.http.HttpClient |
需要精细连接池、拦截器链 |
| JSON | 无官方绑定（按 JDK 版本核对） | 需要流式解析、注解映射 |
| 集合扩展 | java.util + 少量工具方法 |
需要原始类型集合避免装箱 |
| 并发编排 | CompletableFuture、虚拟线程 |
需要结构化并发或复杂重试 |
HttpClient client = HttpClient.newBuilder()
.connectTimeout(Duration.ofSeconds(2)).build();
HttpResponse<String> resp = client.send(
HttpRequest.newBuilder(URI.create(url)).GET().build(),
HttpResponse.BodyHandlers.ofString());
标准库也不是道德高地：它缺的能力自己补两百行，边界、编码、超时、异常语义都要自己测，判据是总拥有成本。
4. 抽象层数量决定替换成本
替换成本几乎完全由"业务代码对库的直接引用面"决定。同一个库，直接调用和隔一层端口，退出成本差一个数量级。
| 接入方式 | 替换要改的地方 | 适用 |
|---|---|---|
| 业务直接调库 | 所有调用点与测试 | 一次性脚本、验证代码 |
| 单点封装 | 一个类 + 少量调用点 | 能力面窄、用法固定 |
| 端口接口 + 适配器 | 一个适配器 | 核心链路、可能被替换 |
| 防腐层 | 只在边界做模型转换 | 外部语义与本方不同 |
public interface BlobStore { // 业务只依赖语义
void put(String key, byte[] body);
Optional<byte[]> get(String key);
}
final class S3BlobStore implements BlobStore {
private final S3Client client; // 库类型只出现在这一层
public void put(String key, byte[] body) { /* 转换与调用 */ }
public Optional<byte[]> get(String key) { /* ... */ }
}
抽象不是越多越好：每多一层就多一次转换和一次排错跳转。判断标准是这个库两年内是否可能被换掉，是才值得隔离。
5. 同质组件为什么只留一个
同一个能力出现两个实现，是依赖腐化最常见的形态。它不立刻报错，但在升级、排错、序列化、线程模型上持续收税。
| 重复形态 | 直接代价 | 典型来源 |
|---|---|---|
| 两个 JSON 库 | 序列化行为与日期格式不一致 | 不同团队各引一个 |
| 两个 HTTP 客户端 | 连接池翻倍、超时语义不一 | 框架带一个、手引一个 |
| 两套日志门面 | 绑定冲突、日志丢失或重复 | 传递依赖带进旧门面 |
| 两个重试库 | 重试次数叠乘、雪崩放大 | 各层各加一个 |
收敛要在构建层强制，而不是靠 review 记忆：
<plugin><artifactId>maven-enforcer-plugin</artifactId>
<executions><execution><goals><goal>enforce</goal></goals>
<configuration><rules><bannedDependencies>
<excludes><exclude>commons-logging:commons-logging</exclude></excludes>
</bannedDependencies></rules></configuration>
</execution></executions></plugin>
6. 版本策略、升级窗口与大版本迁移
锁死版本和跟随升级都不算策略，升级窗口才是。锁死只是把问题推给未来；跟随会在没有预算时被迫升级。
| 策略 | 收益 | 代价 | 适用 |
|---|---|---|---|
| 完全锁死 | 可复现、变更可控 | 漏洞修复要手动搬 | 稳定期核心链路 |
| 只锁直接依赖 | 可复现与可控兼顾 | 传递依赖仍会漂移 | 多数业务服务 |
| 跟随次要版本 | 修复及时 | 需要回归预算 | 有自动化测试兜底 |
| 跟随大版本 | 不吃技术债 | 迁移成本前置、风险集中 | 平台/基础库团队 |
<dependencyManagement><dependencies>
<dependency>
<groupId>com.example</groupId><artifactId>platform-bom</artifactId>
<version>${platform.bom.version}</version><type>pom</type><scope>import</scope>
</dependency>
</dependencies></dependencyManagement>
升级窗口要写进计划：每季度一次次要版本窗口，大版本单独排期；没有窗口的团队，最终都在"必须升"那天做高风险跳跃。
大版本破坏性变更的顺序不是"改到能编译"，而是先把旧版本关进边界，再在边界内替换：
final class PdfRendererAdapter {
private final com.v1.PdfRenderer legacy; // 旧版本先锁在这里
byte[] render(Doc d) { return legacy.render(d.toV1()); }
}
// 新版本并行实现同一接口 → 按开关灰度 → 旧实现无调用点后删依赖
顺序颠倒会让编译错误变成几百处，每处都要判断语义；漏掉的一处会以线上数据错误出现。
7. 许可证与二方库：责任的归属
许可证的风险不在"能不能用"，而在"用了之后要不要开源、能不能静态链接、分发时要不要带声明"。答案依赖分发形态，而分发形态常在两年后变化。
| 类型 | 实际风险点 | 需要确认 |
|---|---|---|
| 宽松型（Apache/MIT） | 专利与声明条款 | 是否要求保留 NOTICE |
| 传染型（GPL/AGPL） | 分发即触发开源义务 | 服务形态是否构成分发 |
| 弱传染（LGPL） | 动态链接与替换要求 | 是否允许修改与重链接 |
| 内部二方库 | 无人维护、版本随意 | 谁改、谁发布、多久淘汰 |
二方库的问题常比三方更重：没有社区、没有 issue 区、没有替代品。至少钉死三件事——负责人、发布节奏、淘汰条件，否则内部库三年后就是没人敢动的黑盒。
8. 评估流程与退出条件
评估的目标是"知道什么时候不能用"，只跑通 happy path 等于没评估。
Day1 跑通核心场景：最小示例、配置项、必需依赖
Day2 异常路径：超时、重试、并发、空值、超大输入
Day3 与现有栈交叉：日志门面、序列化、线程模型、监控埋点
Day4 压测与内存：单实例吞吐、对象分配、有无无界缓存
Day5 退出演练：写一个替换实现，数一数要改多少处
产出 坑列表 + 退出条件 + 负责人
| 退出信号 | 说明 |
|---|---|
| 连续两个大版本无维护者响应 | 安全修复不可得 |
| 传递依赖阻塞 JDK 升级 | 升级路径被单点卡住 |
| 小版本内改变语义 | 版本号不再表达兼容承诺 |
| 替换演练改动点超阈值 | 隔离层没建好，先补隔离 |
| 许可证与分发形态冲突 | 需法务与架构共同确认 |
退出条件要在引入当天写下："半年不发版就换"比事后争论便宜得多。
9. 排错：五种"像是库有问题"的情况
| 现象 | 更可能的原因 | 处理 |
|---|---|---|
| 启动报类冲突 | 同一门面被带进两个版本 | 看依赖树，排掉旧门面 |
| 偶发序列化失败 | 两个 JSON 库对同一对象行为不同 | 统一到一处序列化边界 |
| 升级后行为变了但能编译 | 次要版本改了默认值或异常语义 | 读 release notes，补契约测试 |
| 内存缓慢上涨 | 无界缓存或未注销监听 | 堆直方图 + 引用链找持有者 |
| 构建不可复现 | 依赖范围被上游放宽 | 锁版本、留依赖树快照 |
10. 边界：这些情况不要做"正规选型"
| 场景 | 结论 | 理由 |
|---|---|---|
| 一次性脚本、数据修复工具 | 随便引，不建抽象 | 生命周期只有几天 |
| 核心链路且团队已深度掌握 | 不换 | 迁移风险大于收益 |
| 功能只用到一个方法 | 自己写十行 | 合同成本高于实现 |
| 停止维护但行为稳定 | 可留，但要隔离 | 稳定优先，前提是有退出路径 |
| 组织强制统一技术栈 | 跟随 | 一致性本身就是收益 |
一句话：组件选型是在买一份长期维护合同。签之前看清期限、违约条款和退出成本；只看功能演示就签，等于把账单留给两年后的自己。
自测
- 评估活跃度你看哪两个指标？为什么提交频率不够？
- 传递依赖从哪三个方向收税？各自怎么观测？
- 什么情况下值得为功能引库，而不是自己写两百行？
- 端口接口与单点封装，替换成本差在哪？要不要隔离的判据是什么？
- 为什么同质组件必须收敛？在构建层怎么强制执行？
- 你的项目里，哪个依赖的退出条件还没写下来？