Go项目启用go build -mod=vendor时，必须将vendor目录提交至git，否则CI构建必然失败；该模式强制只读vendor/、绕过网络和go.mod，若vendor缺失或modules.txt过期，会报“inconsistent vendoring”错误。
Go 项目建议把 vendor 文件夹加入 git，不是“风格偏好”，而是特定构建约束下的确定性保障手段——不加，CI 构建可能在任意时间点静默失败。
哪些场景下 go build -mod=vendor 强制要求 vendor/ 在 git 中
这个 flag 不是装饰品，它会彻底绕过 go.mod 和网络下载，只读 vendor/。一旦启用，而该目录没提交，构建必然报错：
-
go: inconsistent vendoring: vendor/modules.txt is out of date—— 这说明vendor/缺失或内容不全，go mod vendor没执行或没提交 - CI 脚本里写了
go build -mod=vendor，但没配GO111MODULE=on或 Go 版本 - 项目用了
replace指向本地 fork 分支，但 CI 没同步go.mod或没设GOPRIVATE，结果go mod download拉了上游版本，而vendor/里才是你真正测试过的代码
vendor/ 提交后必须同步维护的三个动作
提交只是起点，没人维护的 vendor/ 比不提交更危险：
- 每次
go get或go mod tidy后，必须立刻运行go mod vendor，再检查vendor/modules.txt是否与go.mod的 checksum 一致（它是 vendor 的权威清单，不是go.sum） - 在
.gitignore中显式排除/vendor/**/*_test.go和/vendor/**/testdata/，否则测试文件污染构建、增大体积、引发 IDE 误跳转 - 禁止手动修改
vendor/下的代码 —— 如果真要 patch，应走go mod edit -replace+go mod vendor流程，否则下次go mod vendor会直接覆盖你的修改
为什么 PHP 的 composer install 可以不提交 vendor，而 Go 有时不行
根本差异不在工具，而在构建契约：
- Composer 默认信任
composer.lock+ 网络可通 + proxy 稳定，且install是标准部署步骤；Go 的-mod=vendor是硬性隔离指令，一旦启用，就等于宣告“此构建不依赖任何外部源” - PHP 项目通常部署时能跑命令，而 Go 常见于 Docker 多阶段构建、Air-gapped 内网 CI、嵌入式交叉编译等无法现场拉包的场景
- 私有模块若没配置
GOPRIVATE=*.corp.example.com，go mod download会尝试走 public proxy，失败即中断；vendor/是唯一兜底
真正麻烦的从来不是“要不要提交”，而是提交之后没人核对 vendor/modules.txt 和 go.mod 是否对得上，或者在 .gitignore 里漏掉了测试文件路径 —— 这些细节一错，构建就从“可复现”退化成“看运气”。
