go build挂起通常非编译器自身卡死，而是本地环境阻塞：内存不足、磁盘I/O延迟高、GOROOT/GOPATH缓存损坏；常见于“loading modules”或“finding imports”阶段，可强制代理、清理mod/cache、禁用vendor、检查模块图、降低并发或清除GOCACHE解决。
编译器挂起不是 Go 编译器本身卡死，而是你本地环境里某个环节被阻塞或资源耗尽——最常见的是 go build 进程卡在 GC 扫描、符号解析或模块依赖图构建阶段，本质是内存不足、磁盘 I/O 延迟高，或 GOROOT/GOPATH 路径下存在损坏的缓存。
go build 卡在 “loading modules” 或 “finding imports” 怎么办
这通常不是代码问题，而是模块代理或本地缓存异常：
- 先执行
go env -w GOPROXY=https://proxy.golang.org,direct强制走官方代理（国内可换为https://goproxy.cn） - 删掉
$GOPATH/pkg/mod/cache/download下的vcs子目录（不是整个mod目录），避免 Git 仓库元数据损坏导致反复拉取失败 - 临时禁用 vendor：加
-mod=readonly参数跑一次go build -mod=readonly，看是否绕过 vendor 初始化卡点 - 检查
go list -m all是否能快速返回——如果它也卡住，说明模块图有环或某依赖仓库不可达
go build 卡住且 CPU 100%、RSS 持续上涨
这是典型的内存型卡顿，尤其在 macOS 或低配 Linux 上常见，和 Go 1.21+ 的模块缓存压缩逻辑有关：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
top -pid $(pgrep -f "go build")看进程 RSS 是否超过 2GB；超了就大概率是go mod download解压 ZIP 包时 OOM 被内核 kill，但进程没退出 - 临时降低并发：设
GODEBUG=gocacheverify=0关掉校验，再加GOPROXY=direct避免中间代理解压压力 - 删掉
$GOCACHE（默认是$HOME/Library/Caches/go-build或$HOME/.cache/go-build），旧缓存可能含损坏的 .a 文件，导致链接器反复重试 - 别用
go build ./...扫全项目——改用明确路径如go build cmd/myapp，减少模块图遍历范围
go test 卡在 “running tests” 不输出、无 goroutine 堆栈
这不是测试逻辑卡住，而是 go test 启动时被 runtime 初始化阻塞，根源常是：
立即学习“go语言免费学习笔记（深入）”；
-
GOMAXPROCS设得过高（比如 128），而系统实际 CPU 数少于一半，调度器初始化慢；临时设为GOMAXPROCS=4再试 - 项目根目录下有巨型
vendor/（>50MB），go test会扫描所有文件做 import 分析；用go test -v -work看临时工作目录路径，然后ls -lSh查最大文件 - 某些 CGO 依赖（如 sqlite3、openssl）在静态链接阶段卡住，表现为
ld进程长时间占用 CPU；加-ldflags="-linkmode=external"强制动态链接绕过 - IDE（如 VS Code）后台启用了
dlv dap调试服务，它会 hook 所有go命令并注入调试桩——关掉 IDE 的 Go 扩展或删掉.vscode/settings.json里的"go.delveConfig": "dlv-dap"
真正难排查的卡点，往往藏在 GOCACHE 和 go/pkg 的二进制缓存里——它们不报错，只默默拖慢一切命令；每次怀疑环境异常，优先清这两处，比重装 Go 更有效。
