Go模块编译失败多因依赖解析卡在网络、校验或路径，需先定位卡点：如“cannot load”或“i/o timeout”是默认代理不可达，应设GOPROXY=https://goproxy.cn,direct并禁用GOSUMDB（可信环境），私有模块需配置GOPRIVATE；“undefined”常因版本不兼容或go.sum损坏，应go mod verify、go clean -modcache后重拉；“permission denied”多因缓存路径无写权限，需检查GOCACHE/GOPATH并确保用户可写；vendor模式须先go mod vendor生成且严格一致，CI中避免混用download与-mod=vendor；真正瓶颈常在依赖解析而非编译器，应通过go build -x定位首步耗时。
Go模块编译失败，八成不是代码问题，而是依赖解析卡在了网络、校验或路径上。直接改go.mod或硬删缓存往往治标不治本，得先定位卡点在哪。
go build卡在“cannot load”或“i/o timeout”
这是国内常见现象，本质是go list -m all阶段尝试连proxy.golang.org或sum.golang.org超时，不是你本地网络差，是 Go 默认代理不可达。
- 临时解决：运行
go env -w GOPROXY=https://goproxy.cn,direct（七牛云代理在国内最稳） - 同时禁用校验服务器：运行
go env -w GOSUMDB=off（仅限内网/可信环境，CI 中慎用） - 如果项目含私有模块（如
git.internal.company.com/repo），必须加go env -w GOPRIVATE=git.internal.company.com/*，否则仍会去 proxy 查找并失败
go build报“undefined: xxx”但明明导入了包
这不是拼写错误，大概率是模块版本不兼容或go.sum损坏导致类型实际没加载进来。
- 先运行
go mod verify检查校验和是否一致；若失败，说明go.sum被篡改或缓存污染 - 执行
go clean -modcache清空模块缓存（路径通常是~/go/pkg/mod），再go mod download重拉 - 若只在升级后出现，用
go list -m all | grep target-module确认实际加载的版本，再比对go.mod中声明的版本是否一致 - 特别注意
indirect依赖——它可能把某个模块拉到高版本，而该版本已移除你要用的函数（如errors.Is在 Go 1.13+ 才有）
编译时提示“permission denied”或“open ... .lock: permission denied”
这通常发生在共享 NFS home 目录、多用户共用GOPATH，或go二进制被 root 安装但普通用户试图写缓存时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要用
sudo go build——它可能污染~/.cache/go-build权限，后续所有构建都会失败 - 检查
go env GOCACHE和go env GOPATH是否指向用户可写路径（如$HOME/.cache/go-build和$HOME/go） - 若
GOCACHE挂载在 NFS 上，建议改成本地路径：go env -w GOCACHE=$HOME/.cache/go-build - 验证方式：
ls -ld $(go env GOCACHE)必须显示当前用户有读写权限
想跳过网络、纯本地编译却仍报错
go build -mod=vendor不是“启用 vendor”，而是“强制只读 vendor”。它要求 vendor 必须存在且完整，且go.mod与vendor/modules.txt严格一致。
- 先运行
go mod vendor生成（注意：它会清空旧 vendor 并重建） - 构建时必须显式加
-mod=vendor，否则 Go 仍会走网络解析 - CI 中若混用
go mod download和go build -mod=vendor，前者会浪费时间且无意义 - vendor 目录超过 50MB 后，文件遍历 I/O 成瓶颈，尤其在 WSL2 或 NFS 上；此时应清理未用依赖：
go mod tidy -v+go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | xargs -r go list -f '{{if .Stale}}STALE: {{.ImportPath}}{{end}}'
真正耗时的从来不是 Go 编译器本身，而是每次构建都重复做依赖发现、校验、下载。盯住go build -x输出的第一行，那里藏着真正的瓶颈。别急着重写代码，先看它卡在哪一步。
