go mod vendor 是将 go.mod 和 go.sum 中声明的所有依赖源码复制到本地 vendor 目录的快照命令，解决离线构建、依赖锁定与审计合规问题；必须配合 go build -mod=vendor 使用，否则默认仍走模块缓存。
go mod vendor 是什么，它解决什么问题
它把 go.mod 和 go.sum 里声明的所有依赖，原样复制到项目根目录下的 vendor 目录中。不是缓存，是快照——所有源码都物理存在本地，构建时不再需要网络拉包，也不受上游仓库删库、改 tag、代理故障影响。
典型适用场景：离线部署、CI/CD 构建隔离、金融/政企等对依赖来源有强审计要求的环境。
- 必须配合
go build -mod=vendor使用，否则 Go 工具链默认仍走模块缓存（$GOPATH/pkg/mod） -
vendor目录一旦生成，就应提交进 Git —— 它是构建契约的一部分，不是临时产物 - 每次更新依赖后（如
go get或go mod tidy），必须重新运行go mod vendor，否则快照过期
go mod vendor 常见失败原因和绕过方式
执行 go mod vendor 报错，90% 是因为本地模块状态不干净或权限/路径异常：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
go: inconsistent dependencies found：说明go.mod和go.sum不匹配，先跑go mod tidy再试 -
no required module provides package ...：项目里 import 了未在go.mod中声明的包，检查拼写或执行go mod tidy - Windows 下路径含空格或中文：Go 工具链某些版本对非 ASCII 路径支持不稳定，建议项目路径纯英文、无空格
- 权限不足导致无法写入
vendor：确保当前用户对项目目录有读写权限，尤其在 CI 中以非 root 用户运行时
CI/CD 中 vendor 快照如何真正生效
只生成 vendor 目录还不够，CI 流水线必须显式启用 vendoring 模式，否则构建仍可能从网络下载：
- 构建命令必须带
-mod=vendor参数，例如：go build -mod=vendor -o server ./cmd/server - 不要依赖
GOFLAGS="-mod=vendor"这类全局设置——CI 环境变量易被覆盖，且部分工具（如gopls）会误判 - 推荐在 Makefile 或构建脚本中固化该参数，避免人工遗漏
- 验证是否生效：构建前删掉
$GOPATH/pkg/mod/cache，再执行构建；若没报网络错误且成功产出二进制，说明确实在用vendor
vendor 不是银弹：它带来的隐性成本
快照带来确定性，也带来维护负担：
-
vendor目录体积大（动辄几十 MB），Git 提交/克隆变慢，建议在 CI 中启用 shallow clone 或 sparse checkout - 安全漏洞修复需手动触发
go get+go mod tidy+go mod vendor全流程，不能靠自动依赖升级工具 - 多人协作时，
vendor目录冲突概率高，合并前务必先go mod vendor重生成，再提交 - 某些私有模块（如用
replace指向本地路径）在vendor中不会被展开，仍需确保 CI 环境能访问对应路径
真正稳定的生产环境，不靠“一次 vendor”，而靠每次依赖变更都强制走完整快照刷新流程，并在构建环节死守 -mod=vendor 这条红线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
