模块机制本身不提升协作效率，真正起效的是团队对go mod的统一执行和配套约定；需固化GOPROXY/GOPRIVATE配置、分层包结构防循环依赖、pre-commit集成go vet/staticcheck、PR强制覆盖及error path测试。
模块机制本身不提升协作效率，真正起效的是团队对 go mod 的统一执行和配套约定。 配置不一致、包结构失控、检查被跳过——这些才是日常阻塞协作的真实瓶颈。
go mod 初始化必须固化 GOPROXY 和 GOPRIVATE
新人本地 go mod download 失败、拉私有模块超时，90% 是代理配置没对齐。硬编码在 shell 配置或 go.env 里极易遗漏，应统一用命令固化：
- 执行
go env -w GOPROXY="https://goproxy.cn,direct"（国内推荐） - 私有模块必须显式设置
go env -w GOPRIVATE="git.internal.company.com/*"，否则go mod会误走公共代理 - 验证是否生效：
go env GOPROXY GOPRIVATE，输出不能是空值或off
漏设 GOPRIVATE 是最隐蔽的坑：报错 “unknown revision”，但错误信息里完全不提代理问题，实际只是模块被当成公开包去 proxy 查了。
包结构必须按职责分层，禁用跨包循环依赖
Go 编译器不报 import cycle 错（仅部分 IDE 或 go list 提示），但运行时 panic 或构建失败常源于此。团队需明确边界：
立即学习“go语言免费学习笔记（深入）”；
- 顶层目录只放
main包和cmd/xxx入口，业务逻辑全部下沉到internal/或pkg/ -
internal/下按领域分包（如internal/user、internal/order），包内函数只能依赖同包或更底层包（如internal/util） - 用
go list -f '{{.Deps}}' ./internal/user快速查依赖树，确认未意外引入internal/order
一旦出现循环依赖，go test ./ 可能静默跳过部分测试——CI 通过，线上行为异常，这不是 Go 的 bug，是包设计失控的信号。
pre-commit 必须强制跑 go vet 和 staticcheck
靠人眼审查没法持续发现资源泄漏、错误忽略、未使用的变量。检查必须变成提交前硬门槛：
- 在
.githooks/pre-commit中加入：go vet ./ && staticcheck ./ - 别用已归档的
golint，改用staticcheck（安装命令：go install honnef.co/go/tools/cmd/staticcheck@latest） - CI 上加严：
go test -race ./，尤其涉及sync.Map或全局变量时
很多人以为 go vet 是可选的“锦上添花”，其实它能提前拦截 fmt 参数类型不匹配、printf 格式串错误等高频低级问题，省掉大量调试时间。
复杂点不在工具链本身，而在于每个成员是否真的把 go mod 当成协作契约来执行——环境变量、包路径、检查脚本，缺一不可。漏掉任意一环，协作就退化为各自为战。
