生成vendor目录可通过go mod vendor命令实现，其核心目的是将项目依赖复制到本地vendor文件夹，确保离线构建与依赖可复现。首先需初始化模块go mod init，再通过go get或go mod tidy管理依赖，最后执行go mod vendor生成目录。构建时使用-mod=vendor标志可强制使用本地依赖。相比go mod tidy仅更新go.mod和go.sum元数据，go mod vendor实际复制依赖代码。是否提交vendor目录至版本控制取决于团队需求：提交可提升可复现性与离线能力，但增加仓库体积；不提交则保持仓库轻量，依赖网络下载。适用于封闭网络或高可控性CI/CD场景，是Go Module生态中平衡外部依赖与项目独立性的关键实践。
在Go语言中，生成
vendor目录并利用
go mod vendor命令，本质上是为了将项目依赖的第三方模块代码复制到项目根目录下的
vendor文件夹中。这样做的好处是，可以让项目在没有网络连接、或者在特定构建环境下，依然能够找到并使用所有依赖，实现一种自包含的、可复现的构建方式。这在某些场景下，比如封闭网络环境、或者对构建过程有极高可控性要求的CI/CD流水线中，显得尤为重要。
解决方案
要生成
vendor目录，并让Go工具链在构建时优先使用它，你需要遵循以下步骤：
-
初始化模块（如果尚未进行）： 如果你的项目还没有
go.mod
文件，你需要先初始化一个Go模块。go mod init your_module_name
这会创建一个
go.mod
文件，标记你的项目为一个Go模块。 -
添加或更新依赖： 在你编写代码的过程中，或者通过
go get
命令引入新的依赖时，Go会自动更新go.mod
和go.sum
文件。go get example.com/some/package
或者，你也可以直接在代码中导入并使用某个包，然后运行
go mod tidy
来自动添加缺失的依赖并移除不再使用的依赖。立即学习“go语言免费学习笔记（深入）”；
go mod tidy
-
生成
vendor
目录： 这是核心步骤。运行以下命令，Go会将go.mod
文件中列出的所有依赖模块的源代码，复制到当前项目根目录下的vendor
文件夹中。go mod vendor
执行完成后，你会在项目根目录看到一个名为
vendor
的新目录，里面包含了所有依赖的源代码。 -
构建时使用
vendor
目录： 默认情况下，Go 1.14及更高版本在vendor
目录存在时，会自动优先使用它。但为了明确指示，或者在一些旧版本环境中，你可以使用-mod=vendor
标志来强制构建过程只从vendor
目录中查找依赖。go build -mod=vendor ./your_main_package
或者运行测试：
go test -mod=vendor ./your_package
为什么选择使用go mod vendor
？它带来了哪些实际好处？
说实话，每次提到
vendor，我心里总有点复杂的情绪。一方面，它似乎有点“复古”，毕竟Go Module的出现就是为了更好地管理依赖，而
vendor某种程度上又把依赖拉回了项目内部。但另一方面，它又确实解决了一些非常实际的问题，是Go Module体系下不可或缺的一环。
最直接的好处，莫过于离线构建能力。想象一下，你的CI/CD服务器在内网环境，无法直接访问GitHub或Go官方代理，或者网络波动频繁。这时候，如果你的项目依赖都打包在
vendor目录里，CI服务器只需要拉取你的代码仓库，就能直接编译，无需再从外部下载任何东西。这极大地提升了构建的稳定性和速度，尤其是在网络条件不佳或者对构建环境有严格限制的场景下。
其次是依赖的明确性和可复现性。虽然
go.mod和
go.sum已经提供了版本锁定和哈希校验，保证了依赖的确定性，但
vendor更进一步，它把依赖的实际代码“冻结”在了你的仓库里。这意味着，无论外部模块仓库发生什么变化（比如某个版本被删除），你的项目依然能用完全相同的代码进行构建。这对于需要长期维护、对构建结果有极高一致性要求的项目来说，简直是福音。它减少了外部环境对构建过程的影响，让你的构建结果更加可预测。
当然，这也不是没有代价的。
vendor目录会显著增加你的代码仓库大小，尤其当你的项目依赖很多或者依赖的模块体积较大时。每次依赖更新，
vendor目录也需要重新生成并提交到版本控制系统。所以，是否使用
vendor，往往是项目团队根据自身实际需求和权衡利弊后做出的决定。对我个人而言，如果不是有明确的离线构建需求或者极其严格的CI环境，我可能更倾向于依赖
go.mod和
GOPROXY。
go mod vendor
与go mod tidy
有什么本质区别？
这两个命令虽然都和Go模块的依赖管理有关，但它们的功能和侧重点是完全不同的。简单来说，
go mod tidy是负责“整理”你的
go.mod和
go.sum文件，而
go mod vendor则是负责“复制”依赖到本地。
go mod tidy的主要职责是同步和清理模块依赖图。当你编写代码，导入新的包，或者删除不再使用的包时，
go.mod文件可能不会立即反映这些变化。运行
go mod tidy会：
-
添加缺失的依赖：扫描你的源代码，找出所有导入但
go.mod
中未声明的模块，并将其添加到go.mod
中，同时更新go.sum
。 -
移除不再使用的依赖：找出
go.mod
中声明了，但你的代码中已经不再导入的模块，将其从go.mod
和go.sum
中移除。 -
更新依赖版本：根据你的代码实际需求和
go.mod
中的约束，调整依赖的版本。
可以把
go mod tidy理解为你的
go.mod和
go.sum文件的“管家”，它确保这两个文件始终是最新、最准确的依赖清单。它并不下载任何代码到你的项目目录，只是管理元数据。
而
go mod vendor，正如我们前面所讨论的，它的核心功能是将
go.mod中列出的依赖模块的实际源代码，复制到项目根目录下的
vendor文件夹中。它不关心你的代码是否导入了某个包，它只根据
go.mod中记录的依赖关系来执行复制操作。它的目标是创建一个自包含的依赖副本，供本地构建使用。
所以，通常的工作流程是：先通过
go get或直接修改代码，然后运行
go mod tidy来更新你的
go.mod和
go.sum，确保依赖清单是正确的。接着，如果你决定使用
vendor模式，再运行
go mod vendor来将这些依赖的实际代码拉到你的项目里。两者是协作关系，而非替代关系。
在团队协作中，vendor
目录应该被提交到版本控制系统吗？
这是一个老生常谈的问题，也是Go社区里一直存在争议的话题。我的观点是，这取决于团队的具体情况和对项目可控性的要求。
如果选择提交vendor
目录到版本控制（例如Git）：
-
优点：
-
极致的可复现性：团队成员拉取代码后，无需执行
go mod tidy
或go mod download
，可以直接构建和运行，因为所有依赖都在本地。 - 离线工作：开发者可以在没有网络的环境下，完全离线地进行开发和构建。
-
CI/CD简化：构建服务器无需网络访问外部Go模块代理，直接使用本地
vendor
目录，简化了CI配置。 -
防止上游变动：即使某个依赖的远程仓库被删除或更改，只要你的
vendor
目录还在，你的项目就不会受影响。
-
极致的可复现性：团队成员拉取代码后，无需执行
-
缺点：
-
仓库膨胀：
vendor
目录通常会包含大量的代码文件，导致Git仓库体积显著增大，克隆和拉取操作变慢。 -
代码审查噪音：每次依赖更新，
vendor
目录下的文件都会大量变动，导致代码审查时难以聚焦于业务逻辑的变更。 -
潜在的“幽灵依赖”：如果
vendor
目录没有及时与go.mod
同步，可能会出现vendor
中存在实际未使用的代码，或者缺失了最新需要的依赖。
-
仓库膨胀：
如果选择不提交vendor
目录（将其添加到.gitignore
）：
-
优点：
- 仓库精简：Git仓库体积小，克隆和拉取速度快。
- 清晰的Git历史：提交记录只包含业务逻辑代码，代码审查更高效。
-
缺点：
-
依赖外部网络：每次新拉取代码或切换分支后，都需要运行
go mod tidy
（或go mod download
）来下载依赖，这需要网络连接。 - 构建时间可能稍长：首次构建或清理缓存后，需要下载依赖，会增加构建时间。
- 环境依赖：构建环境需要能够访问Go模块代理（GOPROXY）。
-
依赖外部网络：每次新拉取代码或切换分支后，都需要运行
我的建议：
对于大多数现代Go项目，特别是那些有稳定GOPROXY支持的团队，我个人倾向于不提交vendor
目录。
go.mod和
go.sum已经足够保证依赖的确定性。通过
go mod tidy和
go mod download（或Go工具链的默认行为），Go能够高效地管理依赖缓存。只有当团队有非常明确的离线构建需求、或者对CI/CD流程有极其严格的、无法通过GOPROXY解决的隔离要求时，才考虑提交
vendor目录。
最终，这需要团队内部达成共识，并根据项目的具体情况、团队的开发习惯以及对构建流程的控制需求来做出决策。没有绝对的对错，只有最适合你的选择。
