博主在编写Go代码时，遇到了这样一个问题：想要修改某个外部包，添加几个函数，而其余功能继续使用，经过调研，发现可以将Go的外部包源码复制到项目本地，对包的代码进行修改，从而达到目的。以下是对Go vendor的介绍。
功能
- 复制依赖到本地
go mod vendor会根据项目的go.mod文件，将所有依赖模块的源代码复制到项目的vendor目录中。这包括直接依赖和间接依赖，但不包括测试文件（如*_test.go）以及依赖模块中的vendor文件夹。 - 离线构建支持通过将依赖项本地化，
go mod vendor允许项目在没有网络连接的情况下进行构建和测试，避免因依赖源不可用或网络问题导致的构建失败。 - **构建时优先使用
vendor**在 Go 1.14 及更高版本中，如果项目目录下存在vendor文件夹，Go 工具链会默认使用vendor中的依赖，而不是从远程仓库下载。
使用场景
- 网络不稳定或依赖源不可用在某些情况下，远程依赖可能会因为网络问题或模块被删除而无法访问。使用
go mod vendor可以确保项目的依赖完整性。 - 构建环境隔离在构建 Docker 镜像或部署到生产环境时，使用
vendor目录可以避免在构建过程中访问外部网络，从而提高安全性和效率。 - 版本控制和依赖审查将
vendor目录提交到版本控制系统（如 Git）中，可以确保团队成员或 CI/CD 环境使用完全一致的依赖版本，同时便于对依赖代码进行审查。
使用方法
-
初始化模块：
go mod init [module-name]生成
go.mod文件。 -
整理依赖：
go mod tidy添加缺失的依赖或移除未使用的依赖。
-
下载依赖：
go mod download将依赖下载到本地缓存。
-
生成
vendor目录：go mod vendor将依赖复制到项目的
vendor目录中。 -
构建时使用
vendor目录：
如果需要显式指定使用vendor，可以使用以下命令：go build -mod=vendor
优点
- 离线构建：确保项目在没有网络的情况下也能正常构建。
- 依赖稳定性：避免远程依赖被删除或版本变更导致的构建失败。
- 安全性：减少对外部网络的依赖，降低安全风险。
缺点
- 增加项目体积：
vendor目录会显著增加项目的存储空间，尤其是依赖较多时。 - 版本管理复杂性：需要手动更新
vendor目录，可能导致版本管理不够灵活。 - 社区趋势：随着 Go Modules 的普及，
vendor的使用逐渐减少，更多项目倾向于直接使用模块缓存和 Go Proxy。
总结
go mod vendor 是 Go Modules 提供的一种依赖管理方式，适用于需要离线构建或对依赖有严格控制的场景。然而，随着 Go Proxy 和模块缓存的完善，其使用频率逐渐降低。在选择是否使用 vendor 时，应根据项目需求权衡其优缺点。
