必须全局强制开启GO111MODULE=on，禁用off和auto模式，通过shell配置、Docker ENV、CI校验三重保障；go.mod须由go mod init和go get生成，禁止手写或replace本地路径；CI嵌入go mod verify、govulncheck、依赖数量比对三道门禁；构建统一加-mod=readonly；模块路径须与仓库URL一致且全项目统一引用。
必须先统一 GO111MODULE=on，否则所有后续标准化动作都会失效。 企业内推广 Go 模块依赖标准化，本质不是教人怎么用 go mod，而是阻断旧习惯、建立可验证的约束边界。关键不在“推”，而在“卡”——让不合规的行为在开发早期就暴露、无法提交、不能构建。
GO111MODULE 环境变量必须全局强制开启
很多团队在 CI 或某台机器上能跑 go mod，但开发者本地仍用 GOPATH 模式，结果是：go build 成功、go test 失败、CI 报 cannot find module。根本原因是 GO111MODULE 默认值为 auto，它会根据当前路径是否在 $GOPATH/src 下自动切换模式，不可控。
- 所有开发者机器需在 shell 配置中永久设置：
export GO111MODULE=on - Docker 构建镜像中必须显式声明：
ENV GO111MODULE=on - CI 流水线每个 job 开头加校验步骤：
test "$(go env GO111MODULE)" = "on" || (echo "GO111MODULE not enabled"; exit 1) - 禁用
off值——它等于主动退回到已被官方废弃的 GOPATH 时代
go.mod 文件必须由工具生成，禁止手写或复制粘贴
常见错误是开发者从旧项目拷贝一份 go.mod，改个模块名就提交，结果 go.sum 缺失、require 里混着伪版本和 commit hash、replace 指向本地路径。这类文件无法复现，也不被 golangci-lint 或 govulncheck 正确识别。
- 新项目初始化只允许一条命令：
go mod init github.com/yourorg/projectname（模块路径须与代码仓库 URL 一致） - 添加依赖必须走
go get，而非手动编辑go.mod：go get github.com/gin-gonic/gin@v1.9.1 - 删除未使用依赖用
go mod tidy，而不是删require行 -
go.mod中禁止出现replace ../local/path—— 临时调试可用-replace参数，但不得进 Git
CI 流程中必须嵌入三道依赖检查关卡
只靠文档或培训没用。真正起效的是把检查变成门禁：提交前、PR 时、合并前，层层拦截。
立即学习“go语言免费学习笔记（深入）”；
- pre-commit 钩子执行：
go mod verify && go list -m -u all | grep -q "updates available" && exit 1 || true（检测篡改与过期依赖） - PR CI 中运行：
govulncheck ./...，发现高危漏洞直接失败 - 主干合并前触发：
go list -m all | wc -l与基线值比对，突增超过 20% 自动告警（防隐蔽引入大体积间接依赖） - 所有构建必须带
-mod=readonly参数，防止构建过程偷偷修改go.mod
开发者本地体验要“零感知”才可持续
如果每次 go run 都要记参数、IDE 提示一堆红色波浪线、go test 因路径问题报错，推广就会变成负担。标准化必须降低认知成本，而不是增加。
- 推荐用
asdf管理 Go 版本，在项目根目录放.tool-versions，IDE（如 VS Code + Go 插件）会自动识别并加载对应版本 - 所有项目根目录放
Makefile，封装成make dev（启动调试）、make test（带覆盖率）、make lint（调golangci-lint），不暴露底层命令 - 禁止要求开发者手动维护
vendor/目录——Go Modules 的设计初衷就是不用它；若因网络原因必须 vendor，应由 CI 统一生成并提交，而非个人行为
最容易被忽略的一点：模块路径（module 声明）不是随便起的别名，它决定了 import 语句能否被其他项目正确引用。一旦定为 github.com/yourorg/foo，所有内部 import 就必须用这个前缀，连测试文件里的 import 都不能写成 ./internal/xxx。路径错位会导致 go list 解析失败，进而让 gopls、testify/mock 生成器全部失效——这种问题往往拖到集成测试阶段才暴露，排查成本极高。
