FastAPI生成OAS3.0.3规范导入报错：不支持anyOf/allOf/oneOf

• 全局排查所有schema节点：别只盯着vector_store参数，用文本搜索工具（比如VS Code的全局搜索）在openapi.json里查找anyOf、allOf、oneOf，把所有出现的地方都找出来。比如FastAPI中模型继承、Union类型、Optional结合多类型的场景，都会自动生成这些关键字，很可能你漏了其他位置的实例。

• 递归展开并合并嵌套的schema引用：如果直接替换allOf为$ref，要确认被引用的目标schema本身不含这些关键字。比如假设$ref指向的#/components/schemas/VectorStoreConfig里还有allOf，那引用后问题依然存在。需要把这些嵌套的组合关键字展开，合并成单一schema：比如把allOf里的所有字段合并到同一个properties下，处理重复字段（保留优先级高的，比如子类覆盖父类的字段）。

• 处理请求体顶层的组合关键字：检查requestBody对应的schema，有些情况下整个请求体的schema就是allOf结构（比如FastAPI的Pydantic模型继承父类时）。这种情况要把allOf里的所有schema字段合并，去掉allOf包裹，直接用合并后的properties、required等字段作为顶层schema。

• 替换Union类型生成的anyOf：FastAPI里的Union[A, B]会生成anyOf，如果目标应用不支持，需要根据业务逻辑调整：

  • 如果两种类型可以兼容（比如int和str），可以统一设置为type: string，并添加pattern验证规则覆盖两种情况；
  • 如果业务上只需要保留一种类型，直接删除其他类型分支，保留单一schema。

• 检查nullable字段的替代方式：有些旧应用不支持OpenAPI 3.0的nullable: true，如果你的schema里有这个，可能需要结合type数组（比如type: ["string", "null"]），但要确认目标应用是否支持这种写法；如果也不支持，就去掉nullable，或者根据业务设置默认值。

• 验证修改后的schema合法性：用swagger-editor导入修改后的openapi.json，检查是否有语法错误，同时模拟发送请求，确认请求体结构符合目标应用的要求。有时候修改后可能出现字段重复、required字段缺失等问题，这些也会导致"Invalid Request Body"错误。

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