go mod verify 不能单独使用，因为它仅比对本地缓存模块哈希与go.sum记录是否一致，不下载缺失模块、不更新go.sum、不清理冗余依赖；若go.sum过期或缓存损坏，它会直接报错但不提示根源，必须前置go mod download和go mod tidy确保环境一致。
go mod verify 为什么不能单独用
go mod verify 只做一件事：比对本地已下载的依赖内容哈希值和 go.sum 文件里的记录是否一致。它不下载缺失模块，不更新 go.sum，也不清理冗余依赖。如果 go.sum 本身已过期或本地缓存损坏，go mod verify 会直接失败，但你根本不知道问题出在哪儿。
常见错误现象：go mod verify 报错 “mismatch for module X”，退出码为 1，但 go build 却能成功——说明构建用了缓存里“脏”的包，而 verify 拒绝承认它。
- 必须前置运行
go mod download，确保所有依赖已拉取并校验过一次 - 必须配合
go mod tidy -v，同步go.mod和go.sum，尤其当团队提交了新依赖但没更新go.sum时 - CI 流水线中禁止使用
go get或手动改go.mod，所有变更应通过go mod tidy触发
CI 构建阶段必须加 -mod=readonly
默认情况下，go build 在发现 go.mod 缺少某依赖时会自动添加（等价于隐式执行 go get），这会让构建结果随环境浮动——比如本地开发机有某个私有模块缓存，CI 机器没有，就会导致构建失败或版本不一致。
加上 -mod=readonly 后，只要 go.mod 和 go.sum 声明不完整，构建立即报错，强制开发者显式运行 go mod tidy 再提交。
- 推荐写法：
go build -mod=readonly -o myapp ./cmd/myapp - 该参数不影响
go test，但测试也建议统一加上，避免测试时意外拉取新版本 - Docker 多阶段构建中，应在 builder 阶段就启用该参数，防止 COPY 后再触发依赖变更
go.sum 被修改时的典型误操作
go.sum 不是人工维护文件，它的每一行都对应具体模块路径+版本+哈希值。手动删行、调换顺序、补空格，都会让 go mod verify 失败——Go 工具链对格式极其敏感。
常见错误场景：
- IDE 自动格式化时把
go.sum当普通文本处理，破坏了换行或缩进 - Git 合并冲突后手动编辑
go.sum，漏掉某行或拼错哈希 - 用
go mod vendor后又删了 vendor 目录，但没重跑go mod tidy，导致go.sum残留无效条目
正确做法：遇到冲突或怀疑损坏，直接 git checkout go.sum 恢复，再运行 go mod tidy -v 重建。
Docker 构建中复制 go.sum 的必要性
很多 Dockerfile 只 COPY go.mod，忽略 go.sum，以为 go mod download 会自动补齐。但实际中，如果构建镜像时网络不可靠或代理配置异常，go mod download 可能跳过某些间接依赖，导致后续 go mod verify 失败，且错误信息不明确。
稳妥做法是在 go mod download 前就确保 go.sum 存在并完整：
- Dockerfile 中先
COPY go.mod go.sum ./，再RUN go mod download - 多阶段构建中，builder 阶段完成
go mod download后，可额外加一步RUN go mod verify，失败即中断构建 - 若使用私有代理（如 Athens），需确认其返回的哈希与官方校验一致，否则
go.sum记录将不匹配
真正容易被忽略的是：go.sum 里同一模块多个版本共存是正常现象，不要因为看到重复路径就手动删减——那是 MVS 算法选出来的合法组合，删了反而破坏一致性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
