按照定义，openAPI文件留下了一些不明确的地方。因此，即使绑定可以编译，它们也无法正常工作。FooBar和BarFoo模式需要不同，因为它允许接收端实例化正确的对象。

discriminator

下面是它在您的代码中的适应方式：

oneOf

此外，为了使它成为一个工作示例，我添加了鉴别器。

allOf

原则上，您可以放弃“鉴别器”，而是在需要选择的每个模式中使用单个值来定义必需的枚举字段。我怀疑，这将导致代码效率较低，因为将需要完整的模式验证来选择适当的类型。使用鉴别器方法，只需评估一个字段。

同样，原则上，如果您的所有模式在结构上都非常不同，并且一个模式不能代替另一个鉴别器或枚举进行验证，那么就没有必要这样做。在JSON世界中，“一个不能代替另一个验证”的断言是一个非常模糊的定义。我认为在JSON模式中使用它是一个彻头彻尾的错误，因为模式的升级可能会受到威胁。

我使用下面这行代码来发出go代码

--additional-properties=useOneOfDiscriminatorLookup=true

另一个指令将绑定切换到JSON模式兼容模式，即保留模式不匹配的元素。这是一个很长的讨论，为什么你想要这个。现在假设JSON模式有这样的假设是有原因的。

请注意，相同的协议，即实际的JSON文件可以用于Java，但在Java中，您需要使用"allOf“结构来代替。