go 1.14+ 默认不使用 vendor/ 目录，即使存在也会联网拉取模块；必须显式加 -mod=vendor 参数才能强制从 vendor/ 加载，且需确保 go111module=on、有有效 go.mod、已运行 go mod tidy、goproxy=off、gosumdb=off 及 go.sum 完整。
Go 1.14+ 默认不使用 vendor/ 目录，即使它存在，go build 仍会联网拉取模块——这不是配置错误，是模块系统的设计行为。
go mod vendor 为什么没生成 vendor/ 或目录为空
最常见原因是环境未进入模块模式或依赖图不完整：
-
GO111MODULE不是on：尤其在$GOPATH/src下执行时，默认为auto或off，运行go env GO111MODULE确认输出必须是on - 当前目录没有
go.mod，或不在模块根目录（比如在子包里执行命令） - 没先运行
go mod tidy，导致go.mod中缺少间接依赖（// indirect），go mod vendor就无从拷贝 - 私有仓库未设
GOPRIVATE，下载静默失败，vendor/只建了个空壳
go build -mod=vendor 仍报 cannot find module
说明工具链没真正走 vendor/，或内容不匹配：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 漏了
-mod=vendor参数：go run、go test、go list同样需要显式加该 flag，否则跳过vendor/ -
go.mod和vendor/modules.txt版本不一致：例如go.mod写着github.com/sirupsen/logrus v1.9.0，但modules.txt记的是v1.9.1，Go 会尝试 fetch v1.9.0 的校验和，触发网络请求失败 -
replace指向本地路径（如./local/pkg）被忽略：go mod vendor默认只处理远程模块，不会把本地目录拷进去 - 构建平台不匹配：比如代码含
// +build linux，但在 macOS 上执行go mod vendor，对应依赖就不会进vendor/
离线构建失败，但 vendor/ 明明存在
问题往往出在 Go 工具链的“隐式联网”环节，而非 vendor/ 本身：
-
GOPROXY或GOSUMDB没关：即使用了-mod=vendor，go list、go mod download等命令仍会连proxy.golang.org或sum.golang.org；必须设GOPROXY=off GOSUMDB=off -
go.sum缺失或损坏：它不是摆设，go build -mod=vendor仍会用它校验vendor/里的源码哈希；删掉go.sum或让它过期，直接报checksum mismatch - 手动改过
vendor/里的文件：哪怕只改一行，哈希就对不上，校验失败 - 交叉编译时
CGO_ENABLED=0触发纯 Go net 实现，但某些 vendor 包（如旧版golang.org/x/net）可能不含完整 DNS 解析逻辑，导致运行时报错
真正难控的不是 vendor/ 目录本身，而是 Go 工具链多个子命令（go list、go mod verify、go test）对网络的隐式依赖——它们不会报“请检查 GOPROXY”，只会卡住或报看似无关的错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
