S06-A01 · 组件选型治理：JDK / Guava / Hutool / Lombok 的边界

适用读者：要为团队"能不能引这个库"拍板的人。
前置：S06-B05、S06-J01。
覆盖旧文：—（E 驱动）
覆盖扩展：E-S06-012（引入库的隐性成本）、E-S06-014（组件版本矩阵）。
上一篇：S06-J03 · 代码生成：注解处理器与脚手架
下一篇：S06-A02 · 构建可复现与制品治理。

1. 一句话结论

引入一个库的成本不在"jar 多大"，在四件事：版本冲突、安全漏洞、维护责任、团队认知。所以选型的第一原则是"能用 JDK 就不用库"。

成本	具体表现
版本冲突	与框架自带版本打架（S01-J07）
安全漏洞	供应链风险（S01-A02）
维护责任	库停更了谁接
认知成本	新人要多学一套 API

2. 选型四问（E-S06-012）

① JDK 有现成的吗？
   ├── 有 → 用 JDK（零依赖）
   └── 没有 → ② 已有依赖里有没有？（Spring/Guava 常已传递引入）
              ├── 有 → 复用，别再引
              └── 没有 → ③ 团队里有第二个人会用吗？
                        ├── 没有 → 慎引（单点依赖）
                        └── 有 → ④ 维护活跃吗？（最近一次发布、issue 响应）

判据：四问全过才引；任一步"否"，就写清楚"为什么仍然要引"。

3. 组件边界表（可直接当团队规范）

需求	用	不用
字符串判空/连接	`commons-lang3 StringUtils` 或 JDK	不要引 Hutool 就为这个
不可变集合/本地缓存	Guava	不要用 `Collections.unmodifiable` 替代（语义不同）
日期格式化	`java.time`（JDK 8+）	不要用 `SimpleDateFormat`（非线程安全）
JSON	Jackson	不要用 Hutool JSON 混搭
日志	SLF4J + Logback	不要同时引两个门面实现
样板方法	Lombok	不要在实体上用 `@Data`（B02 §5）
对象映射	MapStruct（显式）或手写	不要用反射 `BeanUtils` 做核心链路

4. 版本矩阵与升级（E-S06-014）

项	要求
版本集中管理	parent/BOM（J01）
锁版本	每个外部库有明确版本，不用 `LATEST`
升级评审	主版本升级需回归测试（S06-A02）
安全扫描	依赖漏洞扫描进 CI（S01-A02）

"组件版本矩阵"：一张表记录"服务 × 关键组件 × 当前版本 × 目标版本 × 负责人"，升级时逐行推进。

5. 反模式

反模式	后果
同一功能两套库	行为不一致、包体积膨胀
为一个小工具引大库	传递依赖爆炸
引了库但不锁版本	构建不可复现
用工具库替代框架能力（如 JSON）	生态割裂（注解/序列化不统一）
引入"只有一个人会用"的库	人员一离职就成黑盒

6. 自检（架构师版）

引入库的四类成本分别是什么？
选型四问的顺序为什么不能反？
哪些场景"JDK 就够"，不需要引库？
为什么"同一功能两套库"是反模式？
组件版本矩阵该记哪几列？

7. 下一篇

S06-A02 · 构建可复现与制品治理

选型定完，最后一篇讲"同一 commit 为什么两次构建产物不同"，以及怎么把构建变成可验证的。

本篇属于系列《S06 · Java 工程化与组件》。扩展点 E-S06-012/014。