go111module必须设为on，因auto模式依赖路径判断不可靠（如/tmp下不识别模块），off模式则完全禁用模块功能，导致go mod命令失效；显式启用才能确保模块机制稳定运行。
GO111MODULE=auto 为什么总出错
因为 GO111MODULE=auto 会根据当前路径是否在 $GOPATH/src 或是否存在 go.mod 来决定启用模块模式，但判断逻辑脆弱——比如你在 /tmp/myapp 初始化项目，它可能直接判定“不在模块内”，拒绝识别，报错：no required module provides package。
- 旧 CI 镜像、Docker 容器或未更新 shell 配置的终端常卡在 auto 模式
-
GO111MODULE=off会彻底禁用模块功能，go mod命令全失效，go get不写go.mod - 唯一稳妥做法是全局设为
on：go env -w GO111MODULE=on
go mod tidy 为什么没拉依赖
go mod init 只生成空的 go.mod，不下载、不校验、不补依赖。直接 go build 很可能失败，因为间接依赖缺失。
-
go mod tidy才真正扫描全部import，补全直接/间接依赖，并同步更新go.sum - 手动往
go.mod里硬写require行？没用——下次go mod tidy会把它删掉 - 已有
vendor目录时，go mod tidy默认忽略它；要清理冗余，得加-v参数
私有仓库拉不到：401 Unauthorized 或 404
没配 GOPRIVATE 时，Go 默认走 GOPROXY，对 git.internal.company.com/lib/foo 这类地址也尝试代理拉取，结果不是 401 就是 404。
- 必须显式设置：
go env -w GOPRIVATE="git.internal.company.com,github.com/myorg" - 支持通配符：
go env -w GOPRIVATE="*.company.com" -
GOPROXY末尾加,direct（如https://goproxy.cn,direct）才能让私有域名跳过代理
replace 为什么本地调试有效、CI 构建失败
replace 是开发阶段绕过远程解析的临时方案，但它不传递、不继承、也不被 CI 默认接受。
-
replace优先级永远高于require，但只作用于当前模块 - CI 环境通常设
GOFLAGS="-mod=readonly"，遇到replace直接报错 - 发布前必须删掉
replace行，否则构建时找不到./lib路径 - 验证是否生效：
go list -m all | grep "=>"，看到路径映射才算成功
indirect 依赖悄悄升级了日志格式或 HTTP client 行为——它不会报错，但会让线上请求多出一个 trace header 或默认超时从 30s 缩短到 5s。这类问题只能靠 go mod graph 和 git blame go.mod 追溯，而不是靠分层或锁版本。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
