不能靠go build -v判断依赖是否齐备，因其输出受缓存、gopath降级、静默导入等干扰；应以go list -m all与go mod download -json交叉验证，并强制go mod verify校验完整性。
不能靠 go build 输出是否“下载”来判断依赖是否齐备——它可能静默跳过、缓存命中或回退到 GOPATH 模式。
为什么 go build -v 不适合作为依赖检测依据
构建命令的输出只反映“当前这次”行为，不具可验证性。常见误导场景：
- 本地已有
$GOPATH/pkg/mod缓存，go build -v完全不打印下载行，但 CI 环境是空缓存，必然失败 - 项目根目录没
go.mod，Go 自动降级到 GOPATH 模式，go build会成功，但依赖路径不可控、不可复现 -
go build遇到import但未实际使用（如仅在_test.go或init()中），仍会触发下载，掩盖“真正缺失”的生产依赖
用 go list -m all + go mod download -json 组合做确定性检测
前者列出解析出的全部模块（含间接依赖），后者强制拉取并返回结构化结果，二者交叉验证才可靠：
- 先跑
go list -m all，确认所有预期模块都在输出里（比如你import "github.com/go-sql-driver/mysql"，输出中必须有对应行） - 再执行
go mod download -json all 2>/dev/null | jq -r '.Path'（需装jq），比对是否与上一步完全一致；若有缺失，说明某依赖的go.mod文件不存在或校验失败，Go 回退到了网络直连逻辑 - 加
-x参数看真实动作：go mod download -x all会打印每一步 fetch 命令，出现git fetch或GET https://表明代理失效或模块源不可达
go mod verify 必须嵌入检测流程，否则哈希校验失败会被忽略
go.mod 可被手动编辑，go.sum 却常被误删或不同步——CI 构建时若跳过校验，可能载入被篡改的模块：
-
go mod verify返回非零即失败，应作为构建前必检步骤（放在go build之前） - 若提示
missing hash，不是删go.sum就完事，而是要查清是哪个模块没写入：运行go list -m -u -f '{{.Path}} {{.Version}}' all，再逐个go mod download -json <path>@<version></version></path>触发补全 - 私有模块（如
GOPRIVATE=*.corp.com）也要进go mod verify，只是不走GOSUMDB；若校验失败，大概率是内网镜像未同步完整 checksum
CI 中避免 “看似下载成功，实则漏依赖” 的三个硬检查点
自动化脚本里光写 go mod download 不够，得盯住这三个信号：
- 检查
go env GOPROXY输出是否包含有效地址（如https://goproxy.cn,direct），空值或direct单独存在 = 默认禁用代理，国内环境几乎必挂 - 执行
go list -f '{{.Dir}}' std，输出应为标准库路径；若报错或为空，说明 Go 安装异常或GOROOT错乱，后续所有模块解析都不可信 - 用
go mod graph | head -20抽样看几条关键路径（如主框架 → 日志库 → 编码库），确认没有incompatible或missing字样——这些在go list -m all里不会体现，但会导致构建时 panic
真正难的不是命令组合，而是理解：模块下载是否完成，不取决于“有没有输出”，而取决于“go list -m all 列出的每个模块，都能被 go mod download 成功拉取且通过 go mod verify 校验”。漏掉任一环，自动化脚本就只是看起来稳。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
