springdoc-openapi中处理嵌套POJO时的StackOverflowError问题解析

问题背景

在使用springdoc-openapi项目为Spring Boot 3.x应用生成API文档时，开发人员可能会遇到一个关于嵌套POJO的特殊问题。当定义一个包含自引用结构的POJO类时，系统会抛出StackOverflowError异常，而同样的代码在Spring Boot 2.x环境下却能正常工作。

问题现象

考虑以下典型的嵌套POJO定义：

@Data
public class FieldDescriptor {
    private String name;
    private String type;
    @ArraySchema(schema = @Schema(name = "fields", implementation = FieldDescriptor.class, ref = "FieldDescriptor"))
    private List<FieldDescriptor> fields = new ArrayList<>();
}

在Spring Boot 3.4.4 + springdoc-openapi 2.8.6环境下，当这个类被用作Controller的返回类型时，系统会抛出StackOverflowError。而在Spring Boot 2.7.18 + springdoc-openapi 1.8.0环境下，相同的代码却能正常工作。

技术分析

版本差异的本质

这个问题的根本原因在于springdoc-openapi v1和v2对OpenAPI规范版本的支持不同：

1. v1版本仅支持OAS 3.0规范
2. v2版本默认支持更新的OAS规范版本

问题根源

经过深入分析，这个问题实际上是底层swagger-core库的一个缺陷。当处理自引用类型时，swagger-core在某些情况下无法正确处理递归结构，导致无限循环和堆栈溢出。

解决方案

方案一：强制使用OAS 3.0规范

在application.properties或application.yml中添加以下配置：

springdoc.api-docs.version=openapi_3_0

这个方案通过强制使用与v1版本相同的OAS规范版本，可以避免新版本中的这个问题。

方案二：优化Schema注解

修改POJO中的注解方式，简化Schema定义：

@ArraySchema(schema = @Schema(name = "fields", ref = "FieldDescriptor"))
private List<FieldDescriptor> fields = new ArrayList<>();

这种写法避免了直接指定implementation，减少了swagger-core处理递归结构时的复杂度。

最佳实践建议

1. 版本兼容性检查：升级Spring Boot版本时，应同时考虑相关生态组件的兼容性
2. 递归结构设计：对于包含自引用的数据结构，建议：
   • 控制递归深度
   • 考虑使用DTO模式打破递归链
3. 文档生成策略：对于复杂模型，可以：
   • 使用@Schema注解提供更明确的文档提示
   • 考虑将复杂模型拆分为多个简单模型

总结

这个问题展示了技术升级过程中可能遇到的微妙兼容性问题。理解底层原理（OAS规范版本差异和swagger-core的递归处理机制）对于快速定位和解决问题至关重要。开发者在设计包含递归结构的数据模型时，应当注意这些潜在问题，并选择合适的解决方案。