golang 的 vendor 目录最早出现在 go 1.5，用于解决依赖管理问题。其核心作用是将第三方依赖打包进项目目录，避免因外部依赖变动导致构建不一致。在 vendor 出现前，依赖包全局安装在 $gopath/src 下，容易引发版本不一致问题。vendor 的工作原理是：go 工具链优先从项目根目录下的 vendor 文件夹查找依赖包，若存在则使用，否则再去 $gopath 或远程仓库查找。其优势包括：1. 确保依赖版本一致；2. 提升构建速度；3. 隔离外部变化；4. 支持离线开发。随着 go modules（go 1.11 引入，go 1.16 默认启用）的普及，vendor 使用减少，但仍在老项目或 ci/cd 中保留，且可通过 go mod vendor 命令生成以支持受限部署环境。因此，尽管主流转向 go modules，理解 vendor 仍是掌握 go 项目结构的重要部分。
Golang 的 vendor 目录最早出现在 Go 1.5 版本中，是为了解决依赖管理问题而引入的一种机制。它的核心作用是：将项目所需的第三方依赖打包进项目目录下，避免构建时因外部依赖变动而导致的不一致问题。
在没有 vendor 之前，Go 项目依赖的包都是全局安装在 $GOPATH/src 下的，这种方式容易导致“在我本地跑得好好的，但别人拉下来就出错”的情况。vendor 目录的设计初衷，就是为了解决这个问题，让项目拥有自己独立的依赖副本。
vendor 目录如何工作？
当你在项目根目录下创建一个 vendor 文件夹后，Go 工具链会优先从这个目录查找依赖包，而不是去 $GOPATH 或者远程仓库。
立即学习“go语言免费学习笔记（深入）”；
举个例子：
假设你的项目结构如下：
myproject/
├── main.go
└── vendor/
└── github.com/
└── someuser/
└── somelib/在 main.go 中引用了 github.com/someuser/somelib，那么 Go 编译器会先检查 vendor/github.com/someuser/somelib 是否存在，如果存在就使用它，否则再去 $GOPATH 和远程仓库找。
这样做的好处是：
- 避免不同开发者使用的依赖版本不一致
- 提高构建的可重复性
- 减少对网络的依赖
vendor 的设计初衷和优势
Go 的设计哲学一直强调简单、高效和一致性，vendor 目录的出现正是为了在保持语言简洁的前提下，解决实际开发中的依赖冲突问题。
主要目标包括：
- 锁定依赖版本：确保每个构建都使用完全相同的依赖代码。
- 提升构建速度：不需要每次构建都去下载依赖。
- 隔离外部变化：即使第三方库发生了破坏性更新或删除，也不会影响已有项目的构建。
-
支持离线开发：只要依赖已经放入
vendor，就可以在没有网络的情况下正常编译。
这些考虑点使得 vendor 成为一种轻量级但有效的依赖管理方式，在早期 Go 生态中起到了重要作用。
vendor 现在还常用吗？
随着 Go Modules 的推出（Go 1.11 引入，Go 1.16 开始默认启用），官方推荐使用模块化的方式来管理依赖，vendor 的使用频率已经有所下降。但在一些老项目或特定场景下，比如 CI/CD 构建中，仍然会保留 vendor 目录以确保构建的一致性和稳定性。
如果你使用的是 Go Modules，也可以通过以下命令生成 vendor 目录：
go mod vendor
这在某些部署环境限制访问公网的场景中非常有用。
所以虽然现在主流是 Go Modules，但理解 vendor 的作用和机制，依然是掌握 Go 项目结构的重要一环。
基本上就这些。
