cannot use auth.callOpts (type []"github.com/coreos/etcd/vendor/google.golang.org。。

在经过了很多此下载之后终于将golang的etcd api吧下载成功了
但是出现了一些错误

很多此在github上面下载失败的原因是下面这个链接所说到的
https://github.com/etcd-io/etcd/pull/10044#issuecomment-417125341
可以自己打开翻译看一下
我最终是通过go get github.com/coreos/etcd/clientv3 下载的
我把大神的解释google翻译了一下

---

github自动为项目移动创建重定向，所以github.com/coreos/etcd现在重定向到github.com/etcd-io/etcd，这意味着如果你依赖于github.com/coreos/etcdmaster，或者这个PR或更新的git哈希，你是依赖管理器（或go get）将从中提取代码github.com/coreos/etcd（在重定向之后）github.com/etcd-io/etcd并下载包含导入到go.etcd.io/etcd包的etcd源，但它会认为代码是针对的github.com/coreos/etcd，因此它会认为github.com/etcd-io/etcd导入是针对不同的项目。我相信依赖管理器（或go get）也将go.etcd.io/etcd引入该项目，因为它看到了它的import语句，这意味着你的依赖项中有两个etcd的副本，它们之间有import语句，导致像你这样的错误消息所示。

可能的修复：

• 取决于发布的etcd版本（git标签，如v3.3.9）而不是master，因为所有发布的版本都coreos/etcd在引用中引用，并且可以正常工作。
• 如果需要依赖master，则显式更新所有import语句go.etcd.io/etcd并验证没有直接或传递依赖性github.com/coreos/etcd。

传递依赖案例：

如果某些golang项目对etcd既有直接依赖也有间接依赖，那么它们可能具有以下内容：

 dependsOn 
 dependsOn 
 dependsOn 

这通常很好。依赖管理器（glide，godep，…）将执行版本冲突解决并决定使用“github.com/coreos/etcd @ v3.2.1”作为etcd版本，因为根据semver，它应该与v3兼容。 2.0从传递依赖到project2。最后你得到一个像这样的项目列表传递给go编译器：

但是如果将project1更新为使用go.etcd.io/etcd而不是coreos/etcd？然后你可以像一个依赖树：

 dependsOn 
 dependsOn 
 dependsOn 

对于这样的情况下，依赖关系管理已没有意识到，go.etcd.io/etcd并coreos/etcd在概念上是一样的东西，它甚至不不管他们是哪个版本。所以它导入了两个依赖项。并且go编译器会认为定义的所有类型都与类型go.etcd.io/etcd不同coreos/etcd，这会导致您显示的错误类型。传递给go编译器的项目列表将是：

对于master遇到此问题的etcd的项目，最明显的快速修复是依赖于已发布的etcd版本（git标签，如v3.3.9）而不是master，因为所有已发布的版本都coreos/etcd在引用中引用，并且可以正常工作。

打算使用的项目go.etcd.io/etcd（因为它们依赖于master，来自此PR或更新的git哈希，或者etcd v3.4 +）：

• 必须显式更新其import语句go.etcd.io/etcd。
• 必须解决其传递依赖性的问题。如果任何依赖关系使用etcd 3.3-首选的解决方案是与项目所有者合作以引入依赖的新版本go.etcd.io/etcd。

当etcd v3.4.0发布时，它与v3.3.0之间将存在不兼容性，遗憾的是，依赖管理器将无法检测到（因为3.4+将来自go.etcd.io/etcd和3.3将来自coreos/etcd）。我有点担心这将如何影响生态系统，所以你可以提供一个确切的项目和依赖性的任何细节可能会有所帮助。但从根本上说，这是etd社区必须要解决的问题。

---

在import的时候 应该import “go.etcd.io/etcd/clientv3” 而不是 "github.com/coreos/etcd/clientv3"