必须统一 goproxy 和 goprivate 配置：团队需强制使用项目级 .goproxy.env 设置 goproxy=https://goproxy.cn,direct 及匹配 import 路径的 goprivate；ci/cd 与 pre-commit 必须校验 go.mod/go.sum 一致性，并通过自动化审批流管控依赖升级。
团队成员的 GOPROXY 配置必须强制统一
不同人本地设置 GOPROXY 值不一致，是依赖下载失败、版本不一致的头号原因。有人用 https://proxy.golang.org，有人用 https://goproxy.cn，还有人设成 direct，结果同一行 go build 在 A 机器上成功，在 B 机器上卡住或拉错版本。
实操建议：
- 在项目根目录下放一个
.goproxy.env文件（非 Git 忽略），内容为：GOPROXY=https://goproxy.cn,direct - CI/CD 脚本开头统一执行：
source .goproxy.env && go env -w GOPROXY="$GOPROXY" - 新成员入职 checklist 中明确要求运行该命令，而非仅靠文档提醒
- 禁止在
~/.bashrc或/etc/profile里硬编码GOPROXY——它会覆盖项目级配置
私有模块必须用 GOPRIVATE 显式绕过代理
团队内部 Git 仓库（如 git.company.com/internal/pkg）若没加 GOPRIVATE，Go 会尝试走 GOPROXY 下载，必然 404。更糟的是，某些代理会返回伪造的 200 响应，导致拉到空模块或错误内容。
实操建议：
-
GOPRIVATE必须匹配实际 import 路径前缀，例如：go env -w GOPRIVATE="git.company.com/*,github.com/myorg/*" - 值不能带协议（
https://）或端口，只写域名通配符 - 把
GOPRIVATE和GOPROXY一起写进.goproxy.env，保持原子性 - 验证是否生效：运行
go list -m github.com/myorg/private@latest，不应出现proxy.golang.org相关日志
go.mod/go.sum 提交前必须通过 go mod verify
有人手动编辑 go.mod 添加 require 行，但没运行 go mod tidy，或删了某行却忘了删 go.sum 对应哈希，导致 go build 在 CI 上报错：verifying github.com/some/pkg@v1.2.3: checksum mismatch。
实操建议：
- 所有 PR 的 CI 流水线第一阶段必须跑：
go mod verify && go mod tidy -v && git diff --quiet go.mod go.sum || (echo "go.mod or go.sum modified; run go mod tidy" && exit 1) - 本地 pre-commit hook 加入
go mod verify，失败直接拒绝提交 -
go.sum不允许部分提交——要么全提交，要么全不提交；禁止只提go.mod不提go.sum - 遇到
checksum mismatch，优先go clean -modcache再重试，而不是手动删go.sum行
依赖更新必须走自动化审批流，不能靠个人直推
开发者直接 go get github.com/foo/bar@v2.3.0 后提交，可能引入不兼容变更（比如 v2.x 的 API 已改），而其他成员在本地构建时才发现 panic。更隐蔽的是，go get 可能顺带升级间接依赖，导致 govulncheck 突然报出高危漏洞。
实操建议：
- 禁用所有人对
go.mod的直接修改权限，只允许通过内部 bot（如 Dependabot 克隆版）发起 PR - 每个依赖升级 PR 必须附带：
go list -m -u输出、govulncheck ./...结果、关键变更的 Changelog 摘要 - CI 自动运行
go test ./...+go vet ./...，任一失败则阻断合并 - 主干分支保护规则：至少 1 名 infra 组成员 + 1 名业务 owner approve 才能合入
最易被忽略的点是 GOPROXY 和 GOPRIVATE 的组合行为——它们不是独立开关，而是协同生效的策略对。漏配任意一个，都可能让模块下载在某个环节静默失败，且错误信息极不直观。
