vendor目录需手动初始化，先用go mod init创建go.mod，再执行go mod vendor生成；构建时必须加-mod=vendor参数才真正使用vendor，否则仍读取模块缓存。
vendor 目录不是自动创建的，得手动初始化
Go 在 1.6+ 默认启用 vendor 支持，但不会自动生成该目录。你得明确告诉 Go：「我要把依赖锁进本地」。最直接的方式是用 go mod vendor，前提是项目已启用模块（即存在 go.mod 文件）。
常见错误是直接在没运行 go mod init 的老项目里执行 go mod vendor，结果报错：go: no modules found。先确认当前目录有 go.mod；没有就补上：
go mod init example.com/myproject
再拉取所有依赖并生成 vendor/：
go mod vendor
注意：go mod vendor 只复制 go.mod 中声明的直接和间接依赖，不包含测试专用依赖（如 _test 中 import 的包），除非它们也被主代码引用。
立即学习“go语言免费学习笔记（深入）”；
构建时必须加 -mod=vendor 参数才真正走 vendor
即使有了 vendor/ 目录，go build 默认仍会读取 go.sum 和远程模块缓存（$GOPATH/pkg/mod）。要强制只用本地 vendor/，必须显式指定：
go build -mod=vendor
漏掉这个参数，就等于白放 vendor —— 构建可能成功，但实际加载的是缓存里的版本，和 vendor 内容不一致。CI/CD 脚本里最容易忽略这点，导致本地能过、流水线失败或行为不一致。
验证是否生效？临时删掉 $GOPATH/pkg/mod/cache 或设环境变量 GOPROXY=off，再不加 -mod=vendor 就会直接报错。
vendor 不等于完全隔离，有些路径仍会逃逸
vendor/ 对 import 路径有效，但对以下情况无效：
-
go get命令始终操作模块缓存，不会往vendor/里写 -
go list -m all显示的是模块视图，不是 vendor 文件树 - 某些工具（如
gopls、go vet）默认不读 vendor，需配置"build.buildFlags": ["-mod=vendor"] - 如果
import路径含/vendor/（比如import "myproj/vendor/somepkg"），Go 会拒绝编译
另外，vendor/ 不影响 replace 指令：若 go.mod 里写了 replace github.com/foo => ./local-foo，那 go mod vendor 不会把 ./local-foo 复制进去，而是跳过它——替换路径优先级高于 vendor。
替代方案比 vendor 更轻量，但适用场景不同
如果你只是想离线构建、避免网络波动，go mod vendor + -mod=vendor 是稳妥选择；但若目标是复现精确构建环境（比如安全审计、长期归档），vendor/ 本身不带校验信息，得靠 go.sum 配合。而 go mod download + 打包 $GOPATH/pkg/mod 缓存，反而更接近“完整模块快照”。
Go 1.18+ 还支持 go mod vendor -o vendor.zip（实验性），可压缩打包，适合分发。不过目前仍需手动解压并配合 -mod=vendor 使用。
真正容易被忽略的是：vendor 目录一旦生成，后续 go mod tidy 不会自动更新它。每次改了依赖，都得重新跑一遍 go mod vendor，否则 vendor 和 go.mod 就脱节了。
