隐式可读性是jpms中通过模块图结构自动建立的可读性连接，不依赖requires声明；java.base和自动模块默认具备该特性，聚合器模块借此统一暴露依赖，但不绕过exports封装限制。
隐式可读性（Implicit Readability）是 Java 平台模块系统（JPMS）中一种轻量但高效的依赖管理机制，它不靠 requires 显式声明，而是通过模块图的结构关系自动建立可读性连接。它的核心作用不是“省掉依赖”，而是让某些模块天然对其他模块可见——前提是这些模块已存在于模块路径中，且满足特定条件。
哪些模块默认具备隐式可读性
Java 运行时会为以下两类模块自动建立隐式可读性，无需在 module-info.java 中写 requires：
-
java.base 模块：所有模块都隐式可读 java.base，无论是否声明
requires java.base;。这是 JPMS 的基石，提供java.lang、java.util等基础 API。 -
自动模块（Automatic Modules）：当传统 JAR（无
module-info.class）被放在模块路径（--module-path）而非类路径（-cp）时，JVM 会将其视为“自动模块”。其模块名通常由 JAR 文件名推导（如guava-32.1.3-jre.jar→ 模块名guava），并且所有其他模块默认可读该自动模块——只要它在模块路径上。
聚合器模块利用隐式可读性统一暴露依赖
聚合器模块本身不包含业务代码，只用 module-info.java 做“外观封装”，把多个底层模块聚合成一个逻辑单元。它不写 requires，而是靠隐式可读性让使用者一次性获得全部依赖：
- 例如，构建一个
com.example.platform聚合模块，内容仅是：module com.example.platform {<br> exports com.example.api;<br>} - 同时确保
com.example.core、com.example.logging、com.example.data等模块都在同一模块路径下。 - 下游模块只需
requires com.example.platform;，就能访问到所有被聚合模块导出的包——因为它们已在模块图中彼此可达，JVM 自动建立了隐式可读链。
隐式可读性 ≠ 无约束的自由访问
即使模块 A 隐式可读模块 B，A 仍不能直接使用 B 中未 exports 的包。隐式可读性只解决“能否看到该模块”，不绕过封装规则：
- 若
com.example.utils没有exports com.example.internal;，哪怕它是自动模块且被隐式可读，其他模块也无法访问com.example.internal.Helper。 - 隐式可读性不会让
opens或反射访问自动生效，运行时反射限制依然存在。
何时该用隐式可读性，何时必须显式 requires
判断依据是“依赖是否属于当前模块的实现细节”：
- 用隐式可读性：当你只是把已有模块组织起来供上层调用，不希望下游感知内部组合逻辑（如平台 SDK、测试桩集合）。
- 必须写
requires：当你真正编译期依赖某个模块的类型（比如方法参数含java.sql.Connection），JVM 需要明确知道该依赖存在，否则编译失败。 - 慎用自动模块：虽然它带来隐式可读便利，但会削弱强封装性，且版本冲突风险更高；长期应逐步迁移到命名模块。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
