我正在编写一个 go 模块，它实现一个满足接口的结构。我们只想维护库的单个版本，但我们的客户使用我们的依赖项之一的多个版本。

依赖项提供了我们想要实现的接口，如下所示。

type supercoolinterface interface {
    dooldcoolthing(value string)
}

我们的实现是这样的。

type supercoolimpl struct {}

func (sc *supercoolimpl) dooldcoolthing(value string) {}

新版本的依赖项在类型模块中添加了新类型。

type newtype struct {
  value string
}

依赖项向接口添加了一个方法。

type supercoolinterface interface {
    dooldcoolthing(value string)
    donewcoolthing(value types.newtype)
}

现在，如果我实现新方法，它将无法使用旧版本的库进行编译，因为 types.newtype 不存在。但是，如果我不实现新版本，我就无法满足新版本的接口。

type SuperCoolImpl struct {}

func (sc *SuperCoolImpl) DoOldCoolThing(value string) {}
func (sc *SuperCoolImpl) DoNewCoolThing(value types.NewType) {}

我们是否需要分叉代码才能支持此版本？在带有预处理器的语言中，有一个简单的解决方案，所以我假设 go 一定有一个我缺少的解决方案。

我们计划继续开发并支持这两个版本，因此需要确保两个不同版本保持一致性会很烦人。我希望我可以用反射或类似于 c 预处理器的东西来做一些事情，在其中我可以定义一个预处理器值，并且仅当我们指示库的版本具有正确的类型时才实现该方法。

正确答案

我找到了适合我的情况的解决方案。

感谢@Burak Serdar 为我指明了正确的方向。

我的解决方案是将旧的实现放入 impl/v0 包中，将新的实现放入 impl/v1 包中。

使用旧版本依赖项的客户端将使用 impl/v0，使用新版本依赖项的客户端将使用 impl/v1。

由于golang只编译直接导入的代码，所以只有接口版本正确的包才会被编译，所以双向都会编译成功。

这减轻了我对必须分叉整个库的担忧。

编辑：如果有人使用此解决方案，如果您当前正在使用 go test ./... 运行测试，则会出现一个问题。该命令似乎尝试构建每个模块，无论它是否包含测试。

但是您可以使用 go test $(go list ./... | grep -v ) 排除测试，然后您可以在另一个命令中针对正确的版本运行这些测试。