必须设GO111MODULE=on，否则go mod init不生成go.mod或go mod tidy不拉包；Go 1.16+虽默认启用，但auto/off模式会导致静默失效，需go env -w GO111MODULE=on并验证输出为on。
go mod init 之前必须确认 GO111MODULE=on
很多开发者执行 go mod init 后发现没生成 go.mod，或者后续 go mod tidy 不拉包——根本原因不是命令写错，而是模块模式根本没启用。Go 1.16+ 虽默认开启，但若本地环境曾手动设为 auto 或 off，就会失效。
- 必须运行：
go env -w GO111MODULE=on，然后用go env GO111MODULE验证输出是on - 不建议依赖
auto模式：它只在项目不在$GOPATH/src下才启用，而新手常误把项目放进去，导致静默失败 - 如果项目已在
$GOPATH/src中，GO111MODULE=on会强制走模块路径，不再读取$GOPATH下的旧包
国内拉不到依赖？GOPROXY 必须配成 https://goproxy.cn,direct
执行 go get 卡住、超时、报 403 或返回空响应，90% 是代理配置错误。golang.org 域名被拦截后，部分镜像会伪造响应，看起来像“成功”但实际没下载。
- 唯一推荐配置：
go env -w GOPROXY=https://goproxy.cn,direct -
direct不是可选后缀，缺了会导致私有模块、未打 tag 的 commit、或新发布的包无法回源校验 - 验证方式：
go env GOPROXY输出必须严格等于https://goproxy.cn,direct（注意逗号无空格） - 如果公司有私有仓库，还需加
go env -w GONOPROXY=*.your-company.com
本地多模块开发时 replace 指令不能少
当你拆出 shared、utils 等独立模块，又不想每次改完都 git push + go get，就得靠 replace 指向本地路径。否则 go build 会去远程找，找不到就报错或拉错版本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在主模块的
go.mod中添加：replace example.com/shared => ../shared - 路径必须是相对当前
go.mod的位置，不能用./shared或绝对路径 -
replace只影响当前模块构建，不会上传到代理，发布前删掉即可 - 如果
../shared目录下没有go.mod，go build会直接失败，先确保子模块已go mod init
deploy.sh 里 go build 的 CGO_ENABLED=0 不能漏
一键部署脚本里编译出来的二进制，如果在本地 macOS 上跑没问题，传到 Linux 服务器却提示 not found 或直接段错误，大概率是 CGO 导致的动态链接问题。
立即学习“go语言免费学习笔记（深入）”；
- 服务端部署必须加：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o appname . -
CGO_ENABLED=0强制静态编译，避免服务器缺失libc或其他 C 依赖 -
-ldflags="-s -w"去掉调试信息和符号表，减小体积，加快启动 - 如果项目真用了 cgo（比如连 PostgreSQL 的
pgx），那得换交叉编译方案，不能简单关 CGO
go mod tidy 后，要立刻检查 go.sum 是否更新、go list -m all 是否列出所有预期模块——尤其在多人协作或切换分支后，依赖状态极易不一致。 
