Go Modules是团队协作唯一应启用的依赖管理机制，须禁用vendor手动同步、全局启用GO111MODULE=on、提交go.mod与go.sum且不修改//indirect行，replace仅限个人go.work中使用。
Go Modules 是团队协作中唯一应启用的依赖管理机制，禁用 vendor 目录手动同步，否则不同团队提交的 vendor/ 会因版本不一致引发 merge 冲突和构建失败。
GO111MODULE=on 必须全局启用，不能靠临时设置
很多团队在本地开发时忘记设环境变量，或只在 CI 中设而忽略开发者机器，导致 go mod 行为不一致：有人走 GOPATH 模式、有人走模块模式，go.sum 校验失效、间接依赖版本漂移。
- 所有开发机和 CI 环境统一写入 shell 配置：
export GO111MODULE=on - 禁止在项目中使用
GO111MODULE=off或 unset 它 -
go env -w GO111MODULE=on可持久化，但不如 shell 配置直观可控
go.mod 文件必须提交，且禁止手动修改 // indirect 行
// indirect 是 go mod tidy 自动标注的标记，表示该依赖未被直接 import，仅作为传递依赖引入。手动删改它会导致 go mod verify 失败，CI 流水线阻断。
- 每次新增 import 后，只运行
go mod tidy，不碰go.mod里的任何注释行 - 若需锁定某间接依赖（如安全审计要求），用
go mod edit -require=example.com/pkg@v1.2.3显式写入，而非靠删// indirect强制提升 -
go.sum必须提交，它是校验包完整性的唯一依据
跨团队共享接口时，禁止 replace 指向本地路径
常见错误是 A 团队在本地开发 api 模块时，用 replace github.com/org/project/api => ./api 调试，然后误提交到主干——B 团队拉代码后因路径不存在直接构建失败。
立即学习“go语言免费学习笔记（深入）”；
- 所有
replace语句只允许出现在个人go.work文件中，绝不可进go.mod - 团队间契约应通过独立
github.com/org/project/api仓库 + 语义化版本（如v1.2.0）消费 -
internal/下代码禁止 export，确保外部无法绕过api模块直连实现
真正容易被忽略的是：团队新人常把 go mod vendor 当作“保险操作”，但它在多人协作中不是加固，而是埋雷——vendor/ 目录一旦进入 git，它的更新节奏、提交粒度、冲突解决方式就彻底脱离 go.mod 的声明式控制。信任 go.mod + go.sum，而不是文件快照。
