团队必须统一goproxy和goprivate配置，避免依赖哈希不一致与私有模块拉取失败；go.mod和go.sum须提交且禁止手动编辑；多模块开发应使用go.work而非replace；internal目录不能解决循环依赖，需靠架构约束。
团队必须统一 GOPROXY 和 GOPRIVATE 配置
不同成员本地环境若使用不同代理（比如有人用 https://goproxy.cn，有人直连 direct），会导致 go mod download 拉取的依赖版本哈希不一致，进而触发 go.sum 冲突或校验失败。私有模块更危险：没设 GOPRIVATE 的人会尝试走代理拉取内部仓库，直接报错 module not found。
实操建议：
- 在项目根目录放一个
.envrc（配合 direnv）或setup-env.sh，预设好GO111MODULE=on、GOPROXY=https://goproxy.cn,direct、GOPRIVATE=git.internal.company.com,github.com/our-org/* - CI 流水线中硬编码这些变量，禁止读取用户本地
go env - 新成员入职时，用脚本自动写入
go env -w，而不是靠口头提醒
go.mod 和 go.sum 必须提交，且禁止手动编辑
go.mod 是依赖的“合约”，go.sum 是它的“数字签名”。跳过提交或手动改版本号，等于让构建失去可复现性——你本地能跑，CI 可能因 checksum 不匹配而失败，别人 go build 也可能卡在验证阶段。
常见错误现象：
- IDE 自动执行
go get后未运行go mod tidy就提交，导致go.mod缺少依赖或残留废弃项 - 为绕过某个 bug，手动把
github.com/some/pkg v1.2.0改成v1.2.1，但没更新go.sum，后续go build报checksum mismatch
正确做法：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 所有依赖变更必须通过
go get或go mod edit触发，再跟一次go mod tidy - Git 提交前加 pre-commit hook，检查
go.mod和go.sum是否同步（可用go mod verify）
本地多模块开发统一用 go.work，别依赖 replace
在 monorepo 中，各子服务（如 service/user、pkg/auth）各自有 go.mod，但开发时需要实时看到彼此修改。很多人习惯在根 go.mod 里写一堆 replace，这会导致两个问题：一是 replace 不被 go list -m all 等工具识别，依赖图失真；二是上线前容易忘记删掉，引发生产环境引用路径错误。
推荐方案：
- 根目录运行
go work init，再go work use ./service/user ./pkg/auth，生成go.work -
go.work提交进 Git，所有人开箱即用；go命令自动优先解析本地路径，无需replace - CI 中禁用
go.work（设GOWORK=off），强制走go.mod发布流程，自然隔离开发与构建逻辑
internal 包不是“魔法”，它只约束 import 路径，不解决循环依赖
很多团队以为只要把代码塞进 internal/ 目录，就能防止模块间乱引。但 internal 的规则仅作用于编译期 import 检查：如果 service/a 和 service/b 都在 internal/ 下，且 a 导入了 b，Go 编译器完全允许——这仍是隐式强耦合，只是没暴露给外部而已。
真正要控制依赖流向，得靠结构设计：
- 每个
internal/service/x应只依赖pkg/下的稳定接口，禁止反向依赖其他service/ - 用
go list -f '{{.Deps}}' ./internal/service/a定期扫描，发现非法依赖路径就报警 - CI 中加入
go vet -vettool=$(which unused)检测未使用的包导入，减少隐蔽耦合
go.mod、谁负责审核 go.sum 变更、以及当 go.work 和 CI 构建行为不一致时，以哪边为准——这些都得写进团队的 CODEOWNERS 和 PR 模板里，不能靠“大家自觉”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
