排查隐式依赖风险需将隐式依赖显式化：用jdeps扫描真实字节码依赖，启动时加--illegal-access=deny和--validate-modules强校验，严格审查module-info.java声明，构建中强制使用modulepath而非classpath。
排查隐式依赖风险，核心是把“看不见的依赖”变成“可检测、可验证、可切断”的显式关系。Java模块系统（JPMS）本身不消除隐式依赖，但提供了工具链和声明机制，让它们无处藏身。
用 jdeps 扫描真实字节码依赖
编译后的 class 文件里藏着运行时实际调用的模块线索，jdeps 能精准提取这些信息，比看 import 语句更可靠：
- 运行 jdeps --module-path mods/ --print-module-deps your-app.jar，输出一行模块名列表，就是你真正依赖的最小集合
- 加 --list-deps 查看每个依赖来自哪个模块；加 --multi-release 21 支持多版本字节码分析
- 若输出含 java.base 以外的未声明模块（如 jdk.unsupported），说明存在被反射或内部 API 触发的隐式路径
启动时启用强校验参数
让 JVM 在加载阶段就报错，而不是等运行到某一行才崩溃：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 启动命令加上 --illegal-access=deny：任何反射越界访问立即抛 InaccessibleObjectException
- 加上 --validate-modules：检查模块图是否合法，比如循环依赖、未导出包被引用、requires 冗余等
- 搭配 --show-module-resolution，启动日志会逐行打印每个类从哪个模块加载，一眼识别“本不该出现”的模块
审查 module-info.java 的声明合理性
隐式依赖常源于 module-info 写得太松或太随意：
- 删掉所有没在代码中 import 或 Class.forName() 引用的 requires 行——哪怕 IDE 没报错，也要手动清理
- 避免滥用 requires transitive，除非你明确设计该模块作为“中间依赖枢纽”；否则下游模块可能意外继承你不希望暴露的依赖
- 第三方库若未模块化，JVM 会生成自动模块（如 commons-collections4-4.4.jar → org.apache.commons.collections4），必须在 requires 中显式写这个名称，不能靠猜测
构建流程中强制模块路径隔离
classpath 是隐式依赖的温床，modulepath 才是 JPMS 的运行前提：
- Maven 项目必须配置
true （Maven Compiler Plugin），否则 javac 仍走 classpath 模式 - 编译和运行一律用 --module-path（不是 -cp）指定所有 JAR，包括你自己的模块和第三方自动模块
- 用 jmod list your-module.jmod 确认模块元数据已正确嵌入，而非仅打包成普通 JAR
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
