go mod vendor执行失败最常见原因是未启用go modules模式：必须确保go111module=on、项目根目录存在go.mod、且在模块根下执行；否则命令静默失败或生成空目录。
go mod vendor 执行失败：空目录或报 no modules found
最常见原因是项目还没真正进入 Go Modules 模式。不是“有 vendor 文件夹就行”，而是必须先有 go.mod，且当前 shell 在模块根目录下运行命令。
-
GO111MODULE必须为on（尤其老项目常在 GOPATH 下，默认是auto或off），用go env GO111MODULE确认 - 如果项目原来用 dep/glide，先删掉
Gopkg.lock、Gopkg.toml等旧文件，再跑go mod init example.com/oldproject - 执行
go mod tidy再go mod vendor——tidy会补全缺失的require，否则vendor只复制“已知依赖”，实际构建时可能缺包 - 私有仓库没配
GOPRIVATE？go mod vendor会静默跳过，导致 vendor 目录里少包，但不报错；加-v参数可看到 fetch 失败日志
构建时 vendor 不生效：为什么 go build 还去拉远程包？
有了 vendor/ 目录 ≠ 自动启用 vendor 模式。Go 1.14+ 默认忽略它，必须显式告诉工具链：“这次只许读 vendor”。
- 漏掉
-mod=vendor参数是最常见错误：go build -mod=vendor、go test -mod=vendor、go run -mod=vendor main.go - CI 脚本里别只写
go build，要统一加 flag，或设环境变量GOFLAGS="-mod=vendor"（推荐） - 验证是否真走 vendor：加
-x参数看编译日志，出现类似compile [vendor/github.com/some/pkg]才算成功 - 注意
go list -m all显示的是模块视图，不是 vendor 实际内容；要用go list -mod=vendor ./...查 vendor 覆盖范围
vendor 目录里为什么缺某些包？比如测试依赖或条件编译包
go mod vendor 只复制「当前构建目标实际需要」的包，不是 go.mod 里所有 require 都进 vendor。
- 仅在
_test.go中 import 的包（如gotest.tools/v3），go build不会拉入 vendor；需先跑go test -mod=vendor触发收录 - 带构建标签的包（如
//go:build !windows），若当前 OS 不匹配，对应依赖也不会进 vendor -
replace指向本地路径（如replace github.com/foo => ./local-foo）不会被复制进 vendor，vendor 里只处理远程模块 - vendor 不包含
go.sum校验信息本身，但依赖版本必须和go.sum一致，否则go build -mod=vendor可能因校验失败而中断
老项目维护：要不要把 vendor 提交到 Git？
提交与否取决于团队协作场景和 CI 约束，不是“应该”或“不应该”，而是“值不值得承担体积和更新成本”。
- CI 环境无法联网、或要求 100% 构建可重现 → 提交
vendor/是最稳妥选择（但需同步go.mod+go.sum+vendor/modules.txt） - 团队开发频繁迭代、vendor 目录动辄百 MB → 建议
.gitignore排除，靠go mod download+GOPROXY加速，用go mod verify校验一致性 - 混合方案也常见：CI 流水线里
go mod vendor生成后立即构建，不提交；发布归档时才打包 vendor 用于离线部署 - 注意：IDE（如 VS Code + gopls）默认不读 vendor，提示的“找不到包”可能是编辑器行为，实际
go build -mod=vendor能过——别被红波浪线带偏
go.mod 和构建上下文共同作用的结果。老项目迁移时，最容易卡在“以为目录存在就万事大吉”，结果构建行为漂移、CI 失败、本地和线上不一致——关键不在有没有 vendor，而在每一步是否显式控制了模块模式与构建路径。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
