必须用ClassLoader隔离+sealed class枚举+元数据校验实现版本强类型隔离：不同团队类由专属ClassLoader加载，同名类视为不同运行时类型；ApiVersion用sealed class定义，编译期强制版本选择；模块通过MANIFEST.MF和服务发现校验版本兼容性。
不能靠静态常量“自动”实现版本号的强类型隔离——它本身不携带版本语义，也不参与类型系统校验。真正可行的做法，是把静态常量作为编译期锚点，配合类加载器隔离、模块声明和构建约束，让不同团队的版本在JVM中成为不可互换的类型实体。
用独立 ClassLoader 隔离各团队版本类
每个团队交付的模块（如 auth-core-v2、payment-sdk-v3）必须由专属 ClassLoader 加载，而非共用 AppClassLoader。这样即使两个模块都定义了 public final class Config { public static final String VERSION = "2.1.0"; }，JVM 也视其为完全不同的类型——类全名相同但类加载器不同，无法强制转换、无法共享单例、字段互不可见。
- 团队A的 Config.class → 由 TeamAClassLoader 实例加载
- 团队B的 Config.class → 由 TeamBClassLoader 实例加载
- 二者在运行时属于不同运行时类（Runtime Class），类型系统天然隔离
将版本号升格为 sealed class 枚举标识
避免字符串常量（如 "v2"）参与逻辑分支。改用 sealed class 定义版本契约，使版本选择成为编译期可检查的类型决策：
- 定义 sealed class ApiVersion，子类为 object V2 : ApiVersion()、object V3 : ApiVersion()
- 所有接口方法签名显式接收 ApiVersion 参数，例如 fun handle(request: Request, version: ApiVersion)
- 调用方必须传入具体子类实例（如 V2），编译器拒绝字符串或 null
在模块 jar 中嵌入版本元数据并启动时校验
静态块不适合做兼容性检测，但可在应用主类 main 方法中读取 META-INF/MANIFEST.MF 或 module-info.class，结合 ServiceLoader 加载各模块自报的 VersionDescriptor 实现：
- 每个团队模块在 src/main/resources/META-INF/services/com.example.VersionDescriptor 提供实现类
- 启动时遍历加载，检查是否满足依赖策略（如 “auth-module >= v2.0.0 &&
- 不满足则明确报错退出，不进入后续初始化流程
构建期固化版本语义到字节码签名
利用 Maven/Gradle 插件，在编译后修改 class 文件，将版本号注入关键类的签名属性（如 Synthetic Annotation 或自定义 Attribute）。JIT 编译或反射访问时可通过 Class.getAnnotation() 或字节码解析获取，确保运行时拿到的是构建时确定的值，而非运行时动态拼接的字符串。
- 例如：给 UserServiceImpl 类添加 @BuildVersion("2.1.0")
- 该注解由构建插件写入，不可被运行时篡改
- 监控或路由逻辑据此做类型分发，而非查 Map 或 if-else 字符串匹配
