google/guava

如果你还在手写不可变集合、多值映射或并发工具，Guava 仍有明确价值；但在新代码里，先检查 JDK 和更新的库是否已经覆盖你要用的部分，再决定是否引入。

解决什么问题

Java 开发者经常需要一个可信的不可变列表、一个把同一个键映射到多个值的 multimap、一个图结构，或者一个带容量限制的缓存，又不愿意自己编写和测试这些基础件。没有现成库时，每个项目都重复一遍，还得处理拷贝、null 和并发访问的细节。Guava 用经过测试的类型替代这些自写脚手架，直接接入常规的 Maven 或 Gradle 构建，让团队把时间花在业务逻辑上。代价是多一个依赖要声明和维护。

有什么不同

Guava 最鲜明的特点是兼容性承诺：未标注 @Beta 的 API 声明为无限期保持二进制兼容，README 指出上一次移除这类 API 是 Guava 21.0。对共享库来说，下游消费方可以升级 Guava 而不必重写代码。@Beta 标注的则相反，这些 API 随时可能被修改或删除，项目建议供他人使用的库借助 Beta 检查器 来避免误用。

这个库覆盖面很广，从集合延伸到 I/O、哈希、原始类型和字符串。它提供两个版本：JDK 1.8+ 的主线版，以及源码位于仓库内的 Android 版。Guava 还带一个运行期链接依赖 failureaccess，外加一些仅注解依赖，依赖分析工具和 shade 处理需要把它们算进去。README 的警告也划出了影响设计选择的边界：Java 序列化形式不保证跨版本稳定，这些类也不适合在可信与不可信代码之间做隔离；com.google.common.io 的部分功能在非 Linux 环境可能无法正常工作。

谁值得试

适合：维护共享库的 Java 团队，或者代码的公开签名已经依赖 Guava 类型、希望基础集合工具长期稳定的项目。兼容承诺和 Android 版是选择它而非自建工具 jar 的具体理由。用 Kotlin 的开发者可能发现 Kotlin 标准库已覆盖所需，一位 2023-11-08 的评论者就报告把绝大多数用法迁移走了（评论），这只是个人经历，不是项目声明。

不适合：只需要 JDK 现已提供的一两个辅助方法，或者扫描工具会因几乎没用到的功能而报 Guava 安全公告的项目。后一种情况下，成本是持续的告警分诊，不是一次性的接入决定。Android 开发者应按 README 使用 Android 版，而不是 JRE 版。

使用条件与边界

先选构件：-jre 要求 JDK 8+，-android 面向 Android 和希望兼容 Android 的库；README 介绍了 Maven 与 Gradle 两种声明方式。如果 Guava 类型出现在你的公开 API 中，需要有意通过 api 而不是 implementation 暴露，这会影响所有下游。

更大的成本在持续维护。Guava 体积大、覆盖广，常被漏洞扫描工具标记；2023-11-08 的评论讨论提到，为实际上并不依赖 Guava 的功能处理安全公告是件麻烦事（评论）。这是社区观察，不是项目政策，但属于团队应当纳入考量的维护负担。另一个边界：如果你的代码本身就是库，应避免使用 @Beta API，因为它们可能无预告地变化。

HotRepo 点评

HotRepo 的带日期样本很有限：Guava 在 2026-08-06 至 2026-08-09 出现在日榜，star 从 51,575 增至 51,885，之后在 2026-10-27 的 Java 周榜以第 12 名记录到 +15。这些只是孤立观察，并非连续序列，无法据此判断趋势走向。对一个 2014 年创建的项目，上榜是关注度的快照，不能证明它适合你的构建。引入前，请对照 兼容性与依赖说明 确认你的公开 API 如何暴露 Guava 类型。