SpringBoot2.7启用Swagger：springdoc-openapi对比Springfox优劣势及迁移优势

• 原生适配OpenAPI 3（OAS3）正式规范：Springfox对OAS3的支持停留在3.0.0版本的实验性实现，生成的文档经常出现Schema缺失、响应格式解析错误、参数类型不匹配的问题；springdoc从设计之初就基于OAS3规范开发，和各类文档渲染工具适配无兼容问题，输出的文档格式完全符合官方标准。
• 迁移成本可控：官方提供Springfox注解兼容模块，原有代码中编写的@Api、@ApiOperation、@ApiParam等Springfox注解不需要全量替换，开启兼容配置后即可正常识别，开发团队可以渐进式替换为@Tag、@Operation等标准OAS3注解，不会阻塞版本升级节奏。
• 跟随Spring生态同步迭代：Springfox自2020年发布3.0.0正式版后基本停止维护，Spring Boot 2.6+版本修改默认路径匹配规则后，Springfox会直接启动失败，需要开发者自行编写补丁修复；springdoc会在每个Spring Boot版本发布后快速推出适配版本，不需要开发者自行处理兼容性问题。
• 生态覆盖更全面：原生支持Spring WebFlux、Spring Cloud Gateway、Spring Security OAuth2、Kotlin协程、Spring Data Rest等主流生态组件，不需要额外引入第三方扩展包；Springfox对WebFlux的支持一直处于实验阶段，OAuth2授权调试、网关接口文档聚合等功能都需要自行实现，bug率极高。
• 运行开销更低：对接口元数据扫描逻辑做了针对性优化，中大型项目下启动扫描速度比Springfox快30%以上，不会出现Springfox常见的启动卡顿、重复生成接口路径、接口量级较大时内存溢出的问题。

优势 #

• 开箱即用无额外适配：Spring Boot 2.7默认将MVC路径匹配策略切换为PathPatternParser，Springfox完全不支持该策略，启动会直接抛出路径匹配相关异常，必须手动将配置项spring.mvc.pathmatch.matching-strategy改回旧版的AntPathMatcher，还会连带影响Actuator端点、静态资源映射的性能优化；springdoc 1.6.x及以上版本原生适配Spring Boot 2.7的默认配置，引入依赖后不需要修改全局配置即可正常启动。
• 完美兼容2.7版本新特性：对Spring Boot 2.7新增的Lambda风格Security配置、配置属性绑定新机制、Jakarta Servlet 5.0可选支持都做了适配，不会出现Springfox常见的Swagger资源被安全规则拦截、配置属性不生效、枚举值解析异常等问题。
• 维护状态稳定可靠：Springfox在Spring Boot 2.7环境下运行，至少需要手动注册3~4个自定义Bean才能修复启动报错、文档页404、请求参数解析错误等已知问题，且这些问题没有官方修复渠道；springdoc对应Spring Boot 2.7的版本处于持续维护状态，遇到问题可以快速得到修复。
• 文档调试体验更好：自带的Swagger UI为更新的稳定版本，支持OAS3规范下的自定义请求示例、批量携带公共请求头、SSE响应实时预览等功能，这些都是Springfox内置的旧版Swagger UI不具备的。

劣势 #

• 老注解兼容不完整：如果项目之前重度使用Springfox的非核心注解属性（比如@ApiIgnore的扩展过滤规则、自定义接口排序逻辑），即使开启兼容模式，这部分逻辑也可能出现失效，需要少量调整代码。
• 自定义扩展需要重构：如果之前基于Springfox的扩展接口做了二次开发（比如自定义文档格式导出、内部接口权限标识自动注入），因为springdoc的扩展点设计和Springfox完全不同，这部分代码无法直接复用，需要重新实现。
• 存在少量适配成本：对于长期使用Springfox的开发者，需要花时间熟悉OAS3标准注解和springdoc的配置规则，部分配置项的命名和Springfox存在差异，比如原来的Swagger开关配置对应到springdoc是springdoc.api-docs.enabled，需要简单对照调整。

内容的提问来源于stack exchange，提问作者Deepjyoti Dutta