java模块系统不支持多版本共存，requires仅声明编译期可见性与运行时强制存在性，无版本选择能力；实战中应通过requires static+spi+serviceloader或modulelayer分层实现逻辑隔离。
requires 指令本身不支持“多版本变量依赖共存”——Java 模块系统在设计上禁止同一模块路径中加载同一模块的多个版本。它不是 Maven 或 pip 那样的版本宽松型依赖管理器，而是基于强封装、唯一解析、启动时验证的静态模块图机制。所谓“共存冲突”，本质上是误用场景；真正可落地的实战策略，是通过 requires 的精细化组合 + 运行时隔离手段，实现逻辑隔离下的多版本适配。
明确 requires 的能力边界
requires 声明的是编译期可见性 + 运行时强制存在性，它只做两件事：
- 告诉 JVM：“我这个模块必须能访问 module-A 的导出包，否则编译失败、启动失败”
- 不参与版本选择逻辑——JVM 不会从多个 com.example.utils-1.2.jar 和 com.example.utils-2.0.jar 中挑一个；它只认模块名，且模块名重复即报错：
Module com.example.utils reads package com.example.utils.api from both com.example.utils and com.example.utils - 无法声明“我需要 v1.x，但允许 v2.x 共存”——模块系统没有“软依赖”或“版本范围”语法（不像 Go 的
require example.com/utils v1.5.0）
替代方案：用 requires static + uses + ServiceLoader 实现插件式多版本兼容
当不同业务线需接入不同版本的 SDK（如支付接口 v1/v2），不应让它们同处一个模块层，而应将版本差异下沉为服务契约抽象：
- 定义统一 SPI 接口模块（如
payment-api），仅含PaymentService接口，无实现 - 各版本 SDK 封装为独立模块（
payment-sdk-v1,payment-sdk-v2），均provides payment.api.PaymentService with ... - 主业务模块
requires static payment-api（编译期可选，避免强耦合），并uses payment.api.PaymentService - 运行时通过
ServiceLoader.load(PaymentService.class)动态获取可用实现——v1/v2 可同时存在，由配置或上下文决定加载哪个
实战：用 ModuleLayer 实现运行时模块分层隔离
若必须并行加载两个冲突模块（如旧版日志模块与新版监控模块都含 com.example.log 包），需绕过默认模块层，构建独立模块层：
- 用
ModuleFinder.of(Paths.get("libs/legacy-log-1.0.jar"))单独加载旧版模块 - 调用
Configuration.resolveAndBind(...)构建专属依赖图 - 通过
ModuleLayer.defineModulesWithParent(...)创建新层，并指定其父层为Layer.boot()或应用层 - 该层内模块可安全引用
legacy-log，而主层使用modern-log，互不干扰 - 注意：跨层类不可直接 new 或 import，需通过反射 +
Class.forName(..., false, layer.module(...).getClassLoader())
规避冲突的前置实践
多数“多版本需求”其实源于架构缺陷，优先采用以下方式预防：
- 对外暴露的 API 模块（如
api-core）保持长期向后兼容，用@Deprecated+ 替代方案引导升级，而非并行维护 - 内部实现模块（如
storage-impl）不导出，仅供本模块使用，避免被其他模块意外依赖 - 使用
requires transitive谨慎传递依赖——避免下游模块因间接依赖而被卷入版本矛盾 - 构建时用
jlink打包最小化运行时，剔除未声明requires的冗余模块，从源头减少冲突面
