SpringDoc OpenAPI与Spring WebFlux整合时的Bean验证问题解析

问题背景

在使用Spring Boot 3.4.1及以上版本时，开发者可能会遇到一个典型问题：当项目同时引入springdoc-openapi-starter-webflux-ui依赖后，应用启动时会抛出jakarta.validation.NoProviderFoundException异常，提示无法找到Bean Validation提供程序。这个问题的核心在于依赖配置的不当组合。

技术原理

Spring生态中存在两种主要的Web编程模型：

1. Spring MVC（基于Servlet API）
2. Spring WebFlux（基于响应式编程）

这两种模型需要不同的基础依赖：

• Spring MVC需要spring-boot-starter-web
• WebFlux需要spring-boot-starter-webflux

当开发者错误地混合使用这两种依赖时，特别是同时引入MVC和WebFlux的starter，会导致Bean Validation提供程序无法正确初始化。这是因为Spring Boot的自动配置机制会根据classpath中的依赖来决定如何配置验证基础设施。

解决方案

正确的做法是保持技术栈的一致性：

1. 纯WebFlux应用：

   • 使用spring-boot-starter-webflux
   • 配合springdoc-openapi-starter-webflux-ui

2. 纯MVC应用：

   • 使用spring-boot-starter-web
   • 配合springdoc-openapi-starter-webmvc-ui

深入分析

这个问题在Spring Boot 3.4.1版本后变得明显，可能是因为该版本对自动配置逻辑进行了调整，使得依赖冲突更容易被发现。本质上，这不是SpringDoc OpenAPI本身的问题，而是项目依赖配置的问题。

最佳实践建议

1. 在创建新项目时明确技术选型，避免混合使用MVC和WebFlux
2. 使用Spring Initializr生成项目骨架时，注意选择正确的技术组合
3. 定期检查项目的依赖树（可通过mvn dependency:tree或gradle dependencies）
4. 当遇到验证相关问题时，首先检查是否引入了正确的验证实现（如Hibernate Validator）

总结

这个案例很好地展示了Spring生态中技术栈选择的重要性。开发者需要清楚地理解不同技术组件之间的关系，特别是在响应式编程逐渐普及的背景下，正确区分传统MVC和WebFlux的适用场景至关重要。通过保持技术栈的一致性，可以避免许多类似的配置问题。