Go 1.11+ 默认启用模块管理，但未执行 go mod init 初始化会导致“no required module provides package”错误；必须在项目根目录运行 go mod init 生成 go.mod，模块路径将作为 import 前缀，且需配合 GOPROXY 镜像和 go mod tidy 完成依赖解析。
Go 1.11+ 默认启用模块管理，但很多新手装完 go 后直接 go run main.go 报错“no required module provides package”，本质是没初始化模块或代理未生效——这不是环境没装好，而是模块系统没“启动”。
go mod init 必须在项目根目录执行
模块初始化不是全局命令，它只对当前目录生成 go.mod，且路径名会作为模块导入路径（module path）写入文件。如果乱进目录执行，会导致后续 import 路径错误或依赖无法解析。
- 正确做法：先
mkdir myapp && cd myapp，再go mod init myapp或更规范的go mod init github.com/username/myapp - 错误现象：在
C:\或用户家目录下执行go mod init，生成的go.mod里 module 名可能是C:或Users，后续任何import都会失败 - 补救：删掉错误的
go.mod和go.sum，cd 到干净目录重来；已有代码需同步调整所有import语句前缀
GOPROXY 必须设为国内镜像才可用
默认 https://proxy.golang.org,direct 在国内基本不可用，go get 或 go mod tidy 会卡住或报 timeout / no matching versions。设置后不生效？大概率是没刷新 shell 环境或权限问题。
- 推荐命令（Windows PowerShell）：
go env -w GOPROXY=https://goproxy.cn,direct - 验证是否生效：
go env GOPROXY应输出https://goproxy.cn,direct，不是空或https://proxy.golang.org,direct - 常见坑：在 CMD 里设了，却用 PowerShell 运行；或用了
go env -w但没关重启终端；Linux/macOS 用户忘了source ~/.zshrc
GO111MODULE=on 不再需要手动开启
Go 1.16+ 已强制启用模块模式，GO111MODULE 环境变量设为 off 反而会破坏现代项目结构。除非你明确要兼容老式 GOPATH 工作流（不推荐），否则别碰它。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 检查方式：
go env GO111MODULE输出应为on；若为auto，说明 Go 版本低于 1.16，建议升级 - 不要执行
go env -w GO111MODULE=on—— 多余且可能干扰 IDE（如 GoLand 某些旧版本会误判） - 真正影响行为的是有没有
go.mod文件：有则走模块，无则 fallback（但 fallback 在新版本中已弱化）
依赖下载失败时，先看 go.sum 是否被锁死
go.mod 记依赖版本，go.sum 存校验和。有时 go mod tidy 卡住，不是网络问题，而是 go.sum 里某个包的哈希与远程不匹配，Go 会拒绝写入。
- 典型错误：
verifying github.com/some/pkg@v1.2.3: checksum mismatch - 临时解决：
go clean -modcache清空本地模块缓存，再go mod tidy - 长期规避：避免手动编辑
go.sum；CI/CD 中统一用go mod download预热，而非依赖首次构建时拉取
最常被忽略的一点：模块路径（module 行）一旦写入 go.mod，就不能随意改——改了就得同步更新所有 import，包括测试文件里的 _test.go。很多人重构项目名时只改了目录，忘了这行，结果满屏红色 import 错误。
