go环境默认启用go mod，goproxy必须显式配置国内镜像（如https://goproxy.cn,direct），go mod init需在项目根目录执行且模块名建议用域名前缀，否则易导致依赖解析失败或校验错误。
Go 环境现在默认走 go mod，GOPATH 已不是必需项；但第三方包编译失败、go get 卡住、import 找不到包，90% 都是代理或模块初始化没对。
go mod init 必须在项目根目录执行
很多新手在任意子目录下敲 go mod init myapp，结果生成的 go.mod 里模块名和实际路径不一致，后续 go build 或 go run 会报 cannot find module providing package。
- 正确做法：先
mkdir myproject && cd myproject，再go mod init myproject - 模块名建议用域名前缀（如
github.com/yourname/myproject），避免纯短名导致本地 import 冲突 - 如果已有代码但没
go.mod，不要手动创建空文件——必须用go mod init生成，否则 checksum 会校验失败
GO111MODULE=on 是默认行为，但 GOPROXY 必须显式配
go version >= 1.16 默认启用 modules，但国内不配 GOPROXY 就等于裸连 proxy.golang.org，几乎必卡在 go get 或 go build 的依赖解析阶段。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐配置：
go env -w GOPROXY=https://goproxy.cn,direct（direct表示私有仓库走直连） - 验证是否生效：
go env GOPROXY应输出你刚设的值 - 若公司内网有私有 registry，把
direct替成https://intra.example.com/go，否则go get会跳过它 - 注意：设置后所有新终端都生效，旧终端需重开或
source ~/.zshrc
go build 编译时找不到 main 包？检查工作目录和入口文件
go build 不像 go run 那样自动推导主包位置，它严格依赖当前目录结构和 package main 声明。
- 必须确保当前目录下有且仅有一个
main.go（或含func main()的.go文件），且文件开头是package main - 如果项目有多个
.go文件，全部都要在同一个目录下，不能分散在子目录中（除非用go build ./cmd/myapp指定子包） - 常见错误：
build command-line-arguments: cannot find module providing package command-line-arguments—— 这说明当前目录没有go.mod或没找到main函数 - 临时调试可用
go build -o app .显式指定输出名和当前目录
第三方包编译失败：优先看 vendor 和 go.sum 校验
即使 go get 成功，go build 仍可能失败，典型原因是 go.sum 中的哈希与实际下载内容不匹配，尤其发生在手动替换 vendor 或修改 go.mod 后。
- 先运行
go mod verify，若报错 “mismatch for module”，说明校验失败 - 解决方法：
go clean -modcache清掉本地缓存，再go mod download重拉一遍 - 若用
vendor目录，务必确保go mod vendor后没手动删改其中文件，否则go build -mod=vendor会校验不过 - 注意：某些老项目用
replace指向本地路径，但路径不存在或拼写错误（比如少个../），go build会静默跳过并报“no required module provides package”
真正麻烦的不是装不上 Go，而是 go.mod 里一行 replace 写错、GOPROXY 漏配、或者 go build 时多进了个子目录——这些细节不报明显错误，只让编译器沉默拒绝你。动手前，先 go env 看一眼，比猜半天快得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
