根本原因是Go Modules默认每次构建都走网络解析依赖树，尤其含大量indirect或私有模块时，go list -m all阶段易超时；解决方案包括配置GOPRIVATE、使用go build -mod=vendor跳过网络、清理未用依赖及优化vendor体积。
为什么 go build 会反复拉依赖、卡在 resolve phase？
根本原因是 Go Modules 默认每次构建都走网络解析依赖树，尤其当项目含大量间接依赖（indirect）或私有模块时，go list -m all 阶段容易超时或重试。不是编译器慢，是依赖解析拖了后腿。
- 检查是否所有
go.mod中的私有模块都配置了replace或GOPRIVATE，否则go会尝试去 proxy 查找失败 - 确认没有混用
vendor和go.sum锁定不一致：若用了go mod vendor，必须配go build -mod=vendor，否则仍会联网 - 避免在 CI/CD 中重复执行
go mod download—— 它和go build内部的 resolve 是同一套逻辑，重复调用只会叠加耗时
如何让 go build 跳过网络、只读本地 vendor？
go build -mod=vendor 不是“启用 vendor”，而是“强制仅从 vendor 目录加载依赖”。它会忽略 go.mod 和 go.sum 中的远程路径，完全信任 vendor 内容。
- 先确保 vendor 已生成：
go mod vendor（注意：该命令会清空旧 vendor 并重建，建议加-v看进度） - 构建时显式指定：
go build -mod=vendor -o service ./cmd/service - CI 中推荐组合使用：
GO111MODULE=on CGO_ENABLED=0 go build -mod=vendor -ldflags="-s -w" ...，关闭 CGO 和调试信息能进一步缩短链接阶段
哪些依赖该删、哪些必须锁死？
微服务里最常拖慢编译的是“泛型工具库”和“全量中间件包”，比如 github.com/grpc-ecosystem/go-grpc-middleware —— 只用日志，却拉了 auth、rate-limit、zipkin 全家桶。
- 改用按需导入：例如只用 logging 拦截器，就只 import
github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/logging，而非顶层包 - 用
go mod graph | grep找出未被代码引用的依赖：go list -m all | xargs -I{} sh -c 'go list -f \"{{len .Imports}}\" {} 2>/dev/null || echo {}'，再结合go mod tidy清理 - 对基础组件（如
google.golang.org/protobuf）务必锁定主版本：require google.golang.org/protobuf v1.34.1，避免 MVS 算法在多服务间选不同次版本引发隐性冲突
vendor 目录变大之后，磁盘 I/O 成瓶颈怎么办？
vendor 超过 50MB 后，go build 读取文件耗时明显上升，尤其在 NFS 或 WSL2 文件系统上。这不是 Go 的 bug，是 OS 层面的文件遍历开销。
立即学习“go语言免费学习笔记（深入）”；
- 禁用 vendor 内的测试文件：
go mod vendor -exclude="**/*_test.go"（Go 1.21+ 支持），可减小 20%~30% 体积 - 把 vendor 移到 SSD 分区或 tmpfs（内存盘），并用
GOENV=off避免go工具链反复 stat 环境配置 - 更彻底的做法：用
go install golang.org/x/tools/cmd/goimports@latest配合 pre-commit，从源头减少无用 import，比后期清理 vendor 更高效
indirect 包触发了跨域代理跳转，或者 vendor 目录里残留了已被 go mod tidy 删除但没 git rm 的旧包。动手前先跑一遍 go mod graph | head -20，比盲目加 -pgo 或升级 Go 版本管用得多。 
