必须用vendor的场景包括：内网CI/CD、零网络Docker构建、审计合规SBOM、Go
有，但只在特定场景下必须用——不是“过时了”，而是“退居二线但不可替代”。 Go Modules 是现代项目的默认依赖管理方式，vendor 目录已不再是必需品，但它仍是构建稳定性、离线可靠性和供应链安全的最后一道本地防线。
什么时候必须用 go mod vendor
不是“想用就用”，而是环境或流程倒逼你启用它：
- CI/CD 流水线运行在无外网的内网环境（如金融、政企私有云），
go build无法访问proxy.golang.org或 GitHub —— 此时必须提前生成vendor并用go build -mod=vendor - 生产镜像构建要求“零网络依赖”，Dockerfile 中禁止
go get或模块下载，vendor/就是唯一可信源 - 审计合规强制要求：所有第三方代码必须显式纳入版本控制，
vendor/提交到 Git 后可逐文件比对哈希，满足 SBOM（软件物料清单）生成需求 - Go 版本低于 1.14 的遗留系统（如某些嵌入式交叉编译链），
go mod行为不稳定，vendor是最稳妥的兜底方案
go mod vendor 和 go build -mod=vendor 怎么配才不翻车
这两个命令常被误以为“只要执行了 vendor 就自动生效”，其实关键在参数联动和时机：
git摸鱼周报自动化
下载
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
-
go mod vendor只是“快照复制”：它把go.mod和go.sum里声明的所有依赖（含 transitive 间接依赖）完整拷贝进vendor/，并生成vendor/modules.txt记录来源 -
go build默认仍走 module 模式，不会自动降级读 vendor；必须显式加-mod=vendor才强制关闭远程拉取、仅从vendor/加载 - 常见错误：
go mod vendor后直接go build—— 若本地$GOPATH/pkg/mod缓存了新版依赖，可能绕过vendor导致构建结果不一致 - 正确姿势：
go mod vendor<br>go build -mod=vendor
，且 CI 中建议加go clean -modcache清理缓存再构建
提交 vendor/ 到 Git 吗？为什么有人删它有人留它
这不是风格问题，而是权衡体积、协作效率与确定性的现实选择：
- 提交
vendor/：适合中大型团队或交付型项目。好处是新人git clone && go build -mod=vendor一步到位，无需联网；坏处是 PR 中vendor/变更动辄上千行，Code Review 几乎不可行，Git 仓库膨胀快（常见 20–50MB） - 不提交
vendor/：适合开源小项目或高频迭代服务。依赖由go.sum锁定，体积轻、PR 干净；但要求所有构建环境能稳定访问代理或模块仓库，CI 必须配置好GOPROXY - 折中方案：CI 构建阶段用
go mod vendor生成临时vendor/，但不提交；人工发布前跑一次go mod verify校验go.sum与实际依赖一致性
真正容易被忽略的是：即便用了 vendor，go.mod 和 go.sum 依然必须维护——它们才是版本事实源；vendor/ 只是它的只读副本。一旦你手动改了 vendor/ 里的代码却不更新 go.mod，下次 go mod vendor 会直接覆盖你的修改。
