关于go mod vendor作用及环境配置的技术咨询

1. go mod vendor的核心作用 #

go mod vendor的核心是把当前项目依赖的所有包，从全局模块缓存复制到项目根目录的vendor文件夹里，但它的价值远不止“缓存副本”这么简单：

• 离线构建兜底：把依赖打包进项目后，哪怕断网、依赖源下架或者访问受限，依然能正常编译项目。
• 彻底固化依赖版本：团队成员、CI/CD环境拿到项目代码后，不用再执行go mod tidy拉取依赖，直接用vendor里的代码，完全避免版本不一致导致的问题。
• 适配私有依赖场景：如果项目依赖私有仓库，对于没有权限访问这些仓库的构建环境（比如公共CI平台），直接用vendor里的副本就能完成构建，不用额外配置权限。

2. 为什么要保留项目里的vendor副本？ #

你说的没错，执行go mod vendor前确实要先通过go mod tidy或go get把依赖下载到缓存，但保留vendor有这些不可替代的理由：

• 项目专属，无版本冲突：全局缓存是所有项目共享的，不同项目可能依赖同一包的不同版本，缓存会存多个版本；但vendor只保留当前项目需要的版本，和其他项目完全隔离，不会出现版本冲突。
• 避免缓存丢失风险：缓存可能被手动清理（比如go clean -modcache），或者在新环境里还没拉取；而vendor随项目代码一起提交，拉取代码后直接就能用，不用额外跑拉取命令。
• 依赖审计更直观：要查看依赖的源码时，直接打开vendor目录就能找到对应包，不用去缓存里找复杂的版本路径，方便做代码审计或调试。

3. 配置环境时，选vendor还是模块缓存？ #

没有绝对的“更合适”，看你的使用场景：

• 优先选vendor的场景：
  • 内网开发、无网络环境，没法联网拉取依赖；
  • 团队协作或CI/CD流程，要确保所有人/环境用的依赖完全一致，杜绝版本漂移；
  • 依赖私有仓库，且构建环境无法配置私有仓库的访问权限。
• 优先用模块缓存的场景：
  • 日常开发，经常更新依赖，用缓存能节省磁盘空间（多个项目共享同一版本的依赖）；
  • 依赖的包体积大，不想把大量依赖代码提交到Git仓库，避免仓库臃肿。
• 本质区别：vendor是项目级的专属依赖副本，随项目代码流转；模块缓存是全局共享的存储，只存在于本地环境，两者定位不同，没有优劣之分，按需选择就行。

内容的提问来源于stack exchange，提问作者M.S.