requires声明的是模块间的编译期依赖关系，而非引入变量；它确保jvm和构建系统明确知晓依赖来源、访问权限及导出包，是实现类型安全与封装控制的基础机制。
在模块化环境中，requires 声明不是用来引入“变量”，而是声明对其他模块的**编译期依赖关系**。所谓“第三方变量安全引入”，本质是确保你所依赖的第三方库能被正确识别、加载，并在类型检查、封装控制和运行时行为上保持可控。关键不在于“把变量拉进来”，而在于让 JVM 或构建系统清楚地知道：你要用谁、谁允许你用、谁暴露了你需要的包。
明确 requires 的作用边界
requires 只出现在 module-info.java 中，它表达的是模块之间的依赖图谱，而非变量导入语句。例如：
-
requires java.sql;→ 表示本模块需要 JDK 的 SQL 模块（标准模块） -
requires com.google.gson;→ 表示本模块依赖 Gson 库（前提是该库已模块化并带module-info.class） -
requires static org.junit.jupiter.api;→ 表示仅编译期需要，运行时可选（如测试依赖）
如果第三方库没有模块化（即无 module-info.class），JVM 会将其转为“自动模块”（automatic module），此时 requires 仍可写，但模块名由 JAR 文件名推导（如 gson-2.10.1.jar → 模块名 gson），且无法控制其导出包——这是安全风险的源头之一。
应对未模块化第三方库的安全实践
绝大多数主流第三方库（截至 2026 年中）仍未自带 module-info.class。此时需主动管理其暴露面：
- 避免使用
--permit-illegal-access（Java 16+ 已废弃），它会弱化所有强封装限制 - 若必须反射访问内部 API（如某些 ORM 或序列化库），用最小粒度的
--add-opens，例如：--add-opens java.base/java.lang=your.module.name - 确认该库是否通过
ServiceLoader提供服务；若使用，需在module-info.java中显式uses对应接口，并确保提供方模块也正确provides - 对资源文件（如
META-INF/services/或配置文件）访问失败的情况，优先检查类路径（-cp）与模块路径（--module-path）是否混用——未模块化库应统一放模块路径下，由 JVM 自动建模
验证与调试模块依赖链
光写 requires 不代表真正安全。建议每上线一个模块化版本前执行：
- 运行
java --list-modules | grep -i gson确认模块是否被识别，名称是否符合预期 - 用
jdeps --module-path mods --recursive your.module.name查看实际依赖拓扑，识别隐式依赖或非法强引用 - 启动时添加
--show-module-resolution，观察模块解析过程是否有WARNING: Unknown module类提示 - 对关键第三方库，检查其 Maven POM 是否标注了
Automatic-Module-Name（如 Gson 2.10+ 已添加），这能避免因 JAR 名变动导致模块名漂移
替代思路：绕过 requires 的轻量集成
若项目尚未全面模块化，或第三方库改造成本过高，更务实的做法是：
- 将核心业务代码模块化，但把第三方依赖保留在传统类路径（
-cp），用Class.forName+ClassLoader.getSystemClassLoader()动态加载——牺牲部分编译期检查，换取兼容性 - 使用 jlink 构建精简运行时镜像时，对未模块化库采用
--add-modules ALL-SYSTEM+--limit-modules组合控制可见范围 - 在构建脚本（Maven / Gradle）中启用
javac --module-source-path分离模块源码与传统依赖，实现渐进迁移
