记录一个 etcd 客户端使用的bug，当时折腾了好久。
本文将会按照安装的过程一步步讲述遇到问题以及如何解决。
etcd clientv3 客户端
首先是 etcd clientv3 的初始化，我们根据指定的 etcd 节点，建立客户端与 etcd 集群的连接。
cli,err :=clientv3.New(clientv3.Config{ Endpoints:[]string{"localhost:2379"}, DialTimeout: 5*time.Second, })
实例化一个 client，这里需要传入的两个参数：
- Endpoints：etcd 的多个节点服务地址，因为我是单点本机测试，所以只传 1 个。
- DialTimeout：创建 client 的首次连接超时，这里传了 5 秒，如果 5 秒都没有连接成功就会返回 err；值得注意的是，一旦 client 创建成功，我们就不用再关心后续底层连接的状态了，client 内部会重连。
Go mod 包依赖冲突处理
我使用了 Go Module 管理依赖。引入相应的第三方依赖，主要是 clientv3 `go.etcd.io/etcd/clientv3`。根据 go.mod 文件来处理依赖关系：
$Gomodtidy
命令执行完，报了如下的错误：
go: github.com/keets2012/etcd-book-code/clientimportsgo.etcd.io/etcd/clientv3testedbygo.etcd.io/etcd/clientv3.testimportsgithub.com/coreos/etcd/authimportsgithub.com/coreos/etcd/mvcc/backendimportsgithub.com/coreos/bbolt: github.com/coreos/bbolt@v1.3.5: parsinggo.mod: moduledeclaresitspathas: go.etcd.io/bboltbutwasrequiredas: github.com/coreos/bbolt
看起来 coreos 维护的 bbolt 库声明它的 module 名称是 go.etcd.io/bbolt ，结果在使用它的时候使用的 package path 是 github.com/coreos/bbolt ，导致不一致( etcd#11720 , etcd#11739 )、 etcd#11749 。
显然是 etcd 使用的是错误的 bbolt 的路径。冷静下来，考虑解决办法。幸好，go module 提供 replace 的方法，我们可以使用下面的方法替换：
replacegithub.com/coreos/bbolt=>go.etcd.io/bboltv1.3.5
然而这样替换之后，还是会出现如下的错误：
go: go.etcd.io/bbolt@v1.3.5usedfortwodifferentmodulepaths (github.com/coreos/bboltandgo.etcd.io/bbolt)
按照错误的描述，我们需要再加上一条 replace，使其成为不同的依赖路径。
replacego.etcd.io/bboltv1.3.5=>github.com/coreos/bboltv1.3.5
现在我们再执行 `go mod tidy`，bbolt 的问题已经解决了，但是新问题又来了：
github.com/keets2012/etcd-book-code/clientimportsgo.etcd.io/etcd/clientv3testedbygo.etcd.io/etcd/clientv3.testimportsgithub.com/coreos/etcd/integrationimportsgithub.com/coreos/etcd/proxy/grpcproxyimportsgoogle.golang.org/grpc/naming: modulegoogle.golang.org/grpc@latestfound (v1.32.0), butdoesnotcontainpackagegoogle.golang.org/grpc/naming
搜一下 issue,你会看到 etcd#11563 、 etcd#11650 、 etcd#11707
Etcd 的代码和新版本的 grpc(v1.27.0)冲突，再次施展替换大法，让项目使用老的 grpc:
replace ( google.golang.org/grpc=>google.golang.org/grpcv1.26.0)
再次执行依赖之间的关系，终于不再报错。检查我们的 go.mod 文件，发现很多的 indirect 引用的库，居然还有两个 etcd :
github.com/coreos/etcdv3.3.25+incompatiblego.etcd.io/etcdv3.3.25+incompatiblegithub.com/coreos/bboltv1.3.5// indirect
github.com/coreos/bbolt 之所以显示为 indirect 是因为我们的代码中还没有引用这个 package。当引用之后，就可以看到 indirect 标记没了。
我们的项目中引入了 go.etcd.io/etcd，为什么还会有一个 github.com/coreos/etcd？这两个路径的代码应该也是一样。
由此可以判断肯定是某个库引用 github.com/coreos/etcd 了。我们来搜索下是哪个库？go mod 还提供了其他的命令：
gomodwhy依赖//解释为什么需要包或模块gomodgraph依赖//输出 module 需求图
$Gomodwhygithub.com/coreos/etcdgo: findingmoduleforpackagegithub.com/spf13/cobrago: findingmoduleforpackagegithub.com/spf13/pflaggo: foundgithub.com/spf13/cobraingithub.com/spf13/cobrav1.0.0go: foundgithub.com/spf13/pflagingithub.com/spf13/pflagv1.0.5
或者使用 Go mod graph 查找，执行如下的命令筛选：
Gomodgraph|grepgithub.com/coreos/etcdgithub.com/keets2012/etcd-book-codegithub.com/coreos/etcd@v3.3.25+incompatiblegithub.com/spf13/viper@v1.4.0github.com/coreos/etcd@v3.3.10+incompatible
可以看到是与 github.com/spf13/viper@v1.4.0 相关，github.com/coreos/etcd 使用了 github.com/spf13/cobra@v1.0.0 库, cobra 又使用 viper 的 1.4.0 版本，而 viper@v1.4.0 又使用了 etcd@v3.3.10+incompatible。造成了循环依赖，对于引入依赖来说已经面目全非，原先 go.etcd.io/etcd，现在却成了 github.com/coreos/etcd。
由于 Go module 的一些 bug，以及开源项目使用 Go module 的错误姿势，go module 模式下导致使用 Etcd 代码库困难重重。这里我们已经解决了 etcd clientv3 依赖引入的问题。
