我之前维护跨版本兼容的工具库时正好踩过这个坑，给你分享几个亲测可行的方案，帮你搞定这个兼容难题：

方案一：依赖桥接+条件配置，一个包通吃双环境 #

这个方案能让同一个库包同时在SB2和SB3环境下正常工作，核心思路是借助依赖桥接+Spring的条件配置自动适配：

• 首先在你的库的依赖配置里，把javax.validation:validation-api和jakarta.validation:jakarta.validation-api都设为provided scope，让引入你库的SB2/SB3应用自行提供对应的API依赖，避免冲突
• 接着在库的配置类里，用@ConditionalOnClass做环境判断：
  • 检测到javax.validation.Validator存在（SB2环境），就注册基于javax的校验器实例
  • 检测到jakarta.validation.Validator存在（SB3环境），就注册基于jakarta的校验器实例
• 你的配置类依然保留@Validated+@ConfigurationProperties注解，启动时的配置校验会根据当前类路径上的API自动触发，完全不影响原有校验逻辑

方案二：打包双版本变体，稳妥分离适配 #

如果不想在一个包里折腾复杂的兼容逻辑，最稳妥的方式是给库做两个版本分支：

• SpringBoot 2专属版本：依赖javax.validation:validation-api，代码里继续用javax.validation.constraints下的注解，启动校验和SB2原生配置校验逻辑完全一致
• SpringBoot 3专属版本：把代码里的javax.validation.constraints批量替换为jakarta.validation.constraints，依赖jakarta.validation:jakarta.validation-api
• 最后在库的说明里明确标注：SB2用vX.x系列版本，SB3用vY.y系列版本，用户按需引入，彻底规避依赖冲突

方案三：字节码增强自动转换，零代码修改适配 #

这个属于进阶玩法，适合不想动业务代码的场景：

• 用ByteBuddy或者AspectJ这类字节码增强工具，在类加载阶段自动把代码里的javax.validation.constraints注解替换为对应的jakarta.validation.constraints注解
• 配置增强逻辑只在检测到SB3环境时生效，SB2环境下直接跳过转换
• 这种方式对业务代码零侵入，但要注意处理好类加载顺序和增强时机，避免启动时出现类冲突问题

最后再提一句启动校验的关键：不管用哪个方案，务必在你的配置类上同时标注@ConfigurationProperties和@Validated（SB3里用@Valid也能触发基础校验，但@Validated支持分组校验更灵活），这样Spring Boot在绑定配置到对象时会自动触发校验，一旦配置不满足规则就会直接启动失败，完美实现你要的启动时校验效果。

内容来源于stack exchange