Go开发环境卡顿主因是代理配置不当和缓存路径不合理：GOPROXY需设为https://goproxy.cn,https://goproxy.io,direct；GOCACHE和GOMODCACHE应显式指定SSD路径；gopls需调低并发并禁用高开销分析器；go build应加-trimpath且隔离cgo。
Go开发环境卡在 go mod download、gopls 启动失败、go build 反复重编——基本不是代码问题，而是代理没配或缓存被绕过了。
GOPROXY 必须设，且不能只写一个地址
国内直连 proxy.golang.org 几乎必超时或返回 403；只设 https://goproxy.cn 而不加 direct 会导致私有模块（如公司内网 GitLab）拉取失败。
- 正确写法：
export GOPROXY=https://goproxy.cn,https://goproxy.io,direct - 私有模块场景下，若用 Athens 代理，需确保
GOPROXY指向其地址，并确认 CI runner 或本地网络能访问该服务 - 临时验证是否生效：运行
go env GOPROXY，再执行go mod download -x观察实际请求 URL 是否走代理
GOCACHE 和 GOMODCACHE 别依赖默认路径
默认缓存路径可能落在机械硬盘或受限目录（如某些 macOS SIP 保护路径），导致 I/O 成瓶颈；go clean -modcache 会清空整个模块缓存，但手动删 $GOPATH/pkg/mod 更容易误删或权限出错。
- 显式指定路径更可控：
export GOCACHE=$HOME/.cache/go-build、export GOMODCACHE=$HOME/go/pkg/mod - 确保目标目录所在磁盘是 SSD，且有写入权限（可用
touch $GOCACHE/test快速验证） - 清理缓存优先用命令：
go clean -modcache（安全）而非rm -rf $GOMODCACHE（风险高）
gopls 卡住或 CPU 飙高，先关分析器再调并发
VS Code 中 gopls 启动慢、补全延迟、频繁报红，大概率是分析范围过大或启用了高开销检查器（如 unusedparams、shadow）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 在 VS Code 设置中修改
gopls配置："gopls": { "maxParallelism": 4, "build.allowModfileModifications": false } - 禁用非必要分析器：添加
"analyses": { "unusedparams": false, "shadow": false } - 大型单体项目建议分模块加载：在
go.work中只 include 当前子模块，避免一次性索引全部代码
go build 反复全量编译？检查 -trimpath 和 cgo 影响
即使没改代码，go build 仍耗时长，常见原因是构建路径被写入二进制（触发缓存失效），或项目里混用了 cgo 且未隔离。
- 始终加
-trimpath：它移除源码绝对路径信息，让相同代码在不同机器上生成一致的缓存 key -
cgo包编译极慢，且会污染缓存；把 C 交互逻辑抽成独立包（如pkg/cgosupport），并在其他地方用// +build !cgo跳过 - 避免在
main包里直接 importcgo相关代码，否则每次构建都拖慢整个流程
真正影响速度的往往不是 Go 编译器本身，而是环境配置和工具链对缓存的“信任程度”——一旦某个环节（比如 replace 指向本地路径、go.sum 缺失、GOPROXY 返回 503）让缓存无法命中，整个加速体系就退化成裸奔状态。
