常见原因是go mod vendor只复制实际编译用到的包，而非go.mod中声明的所有包，如_test.go中的导入、//go:embed间接引用、replace指向外部路径未加-v、私有仓库未设GOPRIVATE等均会导致缺包。
go mod vendor 生成失败或 vendor 里缺包，常见原因是什么
不是命令没跑，而是 go mod vendor 只复制「当前构建实际用到的包」——它不看 go.mod 里写了什么，只看你的 .go 文件里 import 了哪些、且这些 import 是否参与主模块编译。
典型缺包场景：
- 某个包只在
_test.go文件里被import，而你运行的是go build（非go test），它就不会进vendor/ - 用了
//go:embed或//go:generate间接引用某包，但没显式import，go mod vendor会跳过 -
go.mod里有replace指向本地路径，但该路径不在项目内（比如指向../common），默认不复制；需加-v参数才尝试包含 - 私有仓库依赖未配置
GOPRIVATE，go mod vendor直接失败，不是静默跳过
验证是否全量：运行 go list -f '{{.Dir}}' all | grep '^vendor/' | wc -l，再对比 go list all | wc -l，数字不一致就说明有遗漏。
go build -mod=vendor 仍报错“cannot find module providing package”
这说明 Go 工具链压根没走 vendor/，而是试图联网拉包。根本原因几乎都是环境或参数没对齐。
立即学习“go语言免费学习笔记（深入）”；
必须同时满足以下三点，-mod=vendor 才真正生效：
-
GO111MODULE=on（Go 1.16+ 默认开启，但 CI 环境常被重置） - 当前工作目录下存在有效的
go.mod（不能是父目录或子目录的） - 命令中明确带上
-mod=vendor——go run、go test、go list全部都要加，不能只给go build加
容易忽略的点：go list -mod=vendor ./... 是最轻量的验证方式，如果它报错找不到包，那其他命令也一定失败。别等 go build 跑一半才暴露问题。
离线构建时，为什么删了 vendor 还不行
因为 vendor/ 只是表象，真正决定构建成败的是三样东西：go.mod、go.sum、以及工具链对校验和与代理的处理。
离线前必须在线环境做完这几件事：
- 执行
go mod tidy && go mod vendor，确保go.sum完整（可用go mod verify验证） - 设置
GOPROXY=off和GOSUMDB=off，否则go build -mod=vendor在某些阶段（如解析模块路径）仍会悄悄连proxy.golang.org - 整个打包带走的必须是：项目根目录 +
go.mod+go.sum+vendor/—— 少任何一个，离线构建都可能中途卡住或校验失败
注意：go.sum 被手动改过、或 vendor/ 里的代码被编辑过，都会触发 checksum mismatch 报错，此时删掉 vendor/ 和 go.sum，重新 go mod tidy && go mod vendor 是最快解法。
要不要把 vendor 提交到 Git
要看团队对构建确定性的要求强度。提交 vendor/ 的本质，是把「依赖源码快照」当成项目源码的一部分来版本化。
适合提交的场景：
- CI/CD 环境完全隔离（无外网、无 proxy）、且不允许任何网络请求
- 发布可分发二进制时，需要保证任意时间点拉出的 tag 都能 100% 复现构建
- 安全审计要求所有依赖代码可追溯、不可变
不建议提交的情况：
- 项目体积敏感（
vendor/动辄百 MB，git status变慢） - 依赖更新频繁，每次
go mod vendor后大量 diff 冲突 - 团队已有强约束的模块管理流程（如统一镜像、私有 proxy）
如果决定提交，记住：vendor/modules.txt 是自动生成的，应加入 .gitignore；而 vendor/ 下所有子目录必须和 go.mod + go.sum 严格一致，否则 go build -mod=vendor 会拒绝构建。
真正难的从来不是 go mod vendor 这条命令本身，而是 Go 工具链在模块解析、校验、缓存多个环节对网络的隐式依赖——它不会告诉你它想连哪儿，直到报错那一刻才暴露。
