如何通过Go dep忽略并阻止vendor目录下的自定义包被删除？

我之前也碰到过类似的依赖困境，结合dep的工作机制，给你几个可行的解决方案：

方案1：用replace强制指定本地伪造的DPkg #

这是最直接有效的方式，让dep完全跳过远程DPkg的拉取，直接使用你在本地（不管是vendor还是自定义目录）的伪造版本。

1. 先把你的伪造DPkg放在项目内的固定目录，比如./local/dpkg（如果已经在vendor里，也可以直接用vendor路径，但更推荐单独目录方便维护）
2. 在Gopkg.toml中添加replace规则：

[[replace]]
  name = "github.com/your/dpkg"  # 替换成DPkg的真实模块路径
  source = "./local/dpkg"       # 替换成你伪造DPkg的本地路径

3. 执行dep ensure -vendor-only，dep会自动将本地的伪造DPkg同步到vendor目录，且后续执行dep ensure时不会再去拉取远程的DPkg版本。

方案2：用override锁定DPkg的版本或源 #

如果你的伪造DPkg是基于某个远程版本修改的，可以用override强制dep使用你修改后的版本：

在Gopkg.toml中添加：

[[override]]
  name = "github.com/your/dpkg"
  source = "./vendor/github.com/your/dpkg"  # 指向vendor中的伪造版本

这种方式会告诉dep：无论远程有什么更新，都优先使用指定路径下的DPkg版本。

方案3：结合ignore和依赖清理 #

如果DPkg对TPkg的依赖是可选的，你也可以直接忽略TPkg的依赖，同时确保DPkg的代码中没有引用TPkg的部分：

1. 在Gopkg.toml中添加对TPkg的忽略：

[[ignore]]
  name = "github.com/your/tpkg"  # TPkg的真实模块路径

2. 手动清理DPkg中所有调用TPkg的代码（你已经确认不会用到这部分，所以没问题）
3. 执行dep ensure -update github.com/your/dpkg，让dep重新解析DPkg的依赖，此时因为TPkg被忽略且代码中无引用，dep就不会再处理TPkg了。

关键注意事项 #

• 一定要确保伪造的DPkg完全移除了对TPkg的所有引用（包括import语句、代码调用），否则编译时还是会报错。
• 优先使用replace方案，它的优先级最高，能彻底避免dep拉取远程依赖。

内容的提问来源于stack exchange，提问作者Alexandre Thenorio