使用vendor目录可锁定依赖版本，确保构建一致性。Go 1.6起支持vendor机制，优先查找项目根目录下的vendor文件夹，实现依赖隔离。早期需手动复制依赖，现推荐用go mod vendor自动生成，配合GOFLAGS="-mod=vendor"或直接使用-go mod=vendor构建，保障离线可构建。vendor目录应提交至版本控制，定期更新以修复安全漏洞，适用于网络受限环境，但现代项目更推荐Go Modules，默认不启用vendor，仅在需要时导出。
在Golang项目中使用vendor目录可以锁定依赖版本，确保构建的一致性和可重复性。从Go 1.6开始，官方支持通过
目录管理第三方依赖。虽然现在Go Modules已成为主流，但在一些旧项目或特定环境中，理解vendor的使用仍然有价值。
vendor目录的作用
vendor目录用于存放项目所依赖的外部包副本
，它位于项目根目录下，优先于
和
被编译器查找。这意味着：
Go编译器会先在当前项目的vendor中查找依赖包
如果找不到，才会去GOPATH或GOROOT中找
这样可以实现依赖隔离，避免不同项目间依赖冲突
手动管理vendor目录
早期没有工具时，开发者需要手动复制依赖到
目录。例如：
vendor/└──github.com/└── gin-gonic/└── gin/├── context.go└── ...
这种方式容易出错且难以维护版本信息，因此不推荐用于生产项目。
立即学习
“
go语言免费学习笔记（深入）
”；
使用工具自动生成vendor
推荐使用工具来管理vendor目录。以
为例（即使使用Modules，也可导出vendor）：
Git
程序猿必备版本控制工具
下载
初始化模块：
添加依赖（自动写入go.mod）：
生成vendor目录：
执行后，项目根目录会出现
文件夹，包含所有直接和间接依赖的代码。
构建时使用vendor目录
启用vendor模式进行构建：
设置
环境变量
：
运行程序：
构建二进制：
此时Go将完全使用vendor中的依赖，即使网络断开或远程仓库不可用也能成功构建。
注意事项与最佳实践
尽管vendor有其优势，但也需注意以下几点：
vendor目录应提交到版本控制系统（如Git），以保证团队一致性
定期更新依赖并重新生成vendor，防止安全漏洞
大型项目中vendor可能很大，影响克隆速度
现代Go开发更推荐使用Go Modules，默认不生成vendor，仅在必要时导出
基本上就这些。如果你的CI/CD环境网络受限，或者需要严格控制依赖版本，
仍然是一个可靠的选择。不复杂但容易忽略的是：记得每次更新依赖后重新运行
，否则vendor目录不会同步变更。
vendor$GOPATH/src$GOROOT/srcvendor/go mod vendorgo mod init your-project-namego get github.com/gin-gonic/gingo mod vendorvendor/GOFLAGS="-mod=vendor"go run -mod=vendor main.gogo build -mod=vendor .go mod vendorgo mod vendor