dep ensure添加新依赖后旧依赖丢失，Gopkg.toml仍有约束的问题咨询

这是使用dep时很容易碰到的问题，我来帮你拆解背后的原因、可能造成的影响，以及对应的解决方式：

为什么之前安装的httprouter会被移除？ #

主要有两个关键原因：

1. dep的核心逻辑：只保留代码实际引用的依赖
   dep ensure命令的核心是基于项目代码的实际引用情况来管理依赖，而不是单纯看Gopkg.toml里的约束。如果你的项目代码里没有真正用到github.com/julienschmidt/httprouter（哪怕你在Gopkg.toml里加了约束），当你执行dep ensure -add安装新依赖时，dep会重新计算整个依赖树，判定httprouter是“未被使用的冗余依赖”，于是就把它从vendor目录和Gopkg.lock里删掉了。

2. 你的项目目录结构有问题
   从你给出的目录结构来看，你把vendor放在了gopath/src/github.com这个根目录下，而不是每个服务（service-auth/service-signup）的独立目录里。dep是基于单个项目根目录来做依赖管理的——如果你在github.com目录下执行dep命令，它会把整个目录当成一个项目来扫描。如果只有其中一个子服务（比如service-auth）用到了httprouter，但dep扫描根目录代码时没发现引用，就会误判这个依赖没用，进而把它删掉。

这种情况会带来哪些影响？ #

• 编译报错风险：要是后续你想在代码里用httprouter，直接就会编译失败——vendor里没这个包，Gopkg.lock也没记录它的版本，dep不会自动帮你恢复。
• 团队协作踩坑：其他同事拉取代码后执行dep ensure，得到的vendor目录里也会没有httprouter，他们的环境同样编译不了项目。
• 依赖管理混乱：Gopkg.toml（声明的约束）和Gopkg.lock（实际安装的依赖）不一致，你很难追踪项目到底依赖哪些版本，后续更新依赖也容易出各种意外问题。

怎么解决？ #

1. 先把目录结构改对
   每个服务都应该是独立的Go项目，各自管理自己的依赖：

   • 进入service-auth目录，执行dep init生成专属的Gopkg.toml、Gopkg.lock和vendor目录。
   • 对service-signup做同样的操作，让每个服务的依赖管理相互独立。
     这样dep只会扫描单个服务的代码，就不会出现跨服务误删依赖的情况了。

2. 保留暂时没用到但需要的依赖
   如果你确定以后要用到httprouter，现在可以在项目代码里加一个空白导入：

   import _ "github.com/julienschmidt/httprouter"
   

   这样dep就会识别到这个依赖被引用了，不会随便把它删掉。

3. 手动重新安装httprouter
   执行下面的命令，重新安装httprouter并更新Gopkg.lock：

   dep ensure github.com/julienschmidt/httprouter
   

内容的提问来源于stack exchange，提问作者R.Roshan