Go编译本身不慢，90%的“感知延迟”源于构建流程瓶颈：模块校验超时、go:generate重复执行、cgo触发C编译、误用-a/-i等过时参数；优化GOPROXY/GOSUMDB、按需生成、禁用-a/-i即可解决。
go build，CI 里卡在 8 秒，大概率不是代码问题，是环境或命令用错了。
go mod init 后为什么 go build 还报 “cannot find module”？
这不是模块没初始化，而是当前目录没被 Go 工具链识别为 module root —— 常见于项目根目录下有 go.mod，但你在子目录（比如 ./internal/handler）里执行 go build。
- Go 默认只在含
go.mod的目录及其子包里解析 import 路径；在子目录运行go build时，它会向上找最近的go.mod，但若该文件里没声明对应路径（如module github.com/you/project），就会 fallback 到 GOPATH 模式并失败 - 正确做法：始终在项目根目录（即
go.mod所在目录）执行构建命令，或显式指定包路径：go build ./cmd/myapp - 验证方式：运行
go list -m，输出应为你的 module 名；若报错或为空，说明当前不在 module 根下
为什么设置了 GOPROXY，go mod download 还超时？
代理配置只是第一步，真正卡住的常是 go.sum 校验失败或 replace 路径失效 —— 尤其当你从旧项目迁移或用了私有 fork 时。
-
go env GOPROXY输出必须包含direct且在末尾，例如：https://goproxy.cn,direct；漏掉direct会导致私有域名（如git.internal.company.com）也走代理，必然 404 -
go.sum中某行 hash 不匹配时，go mod download会静默重试直到超时；可临时用go mod download -x查看具体哪个模块校验失败 - 如果用了
replace指向本地路径（如replace github.com/some/lib => ../some-lib），确保该路径真实存在且含有效go.mod；否则go build会直接报cannot load
如何让 go build 真正“秒级”且稳定？
关键不是加参数，而是砍掉非必要动作。默认 go build 会做依赖解析、语法检查、类型检查、代码生成、链接 —— 其中前几项在缓存命中时极快，但一旦触发网络或磁盘 I/O，就脱离秒级范畴。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 禁用调试符号和 DWARF：生产构建加
-ldflags="-s -w"，省去符号表写入，提速约 15%，且二进制小 30% - 跳过 vendor 检查：如果不用
vendor目录，加-mod=readonly防止意外修改go.mod或go.sum - 限定构建范围：不要
go build .，改用go build ./cmd/myapp—— 避免扫描整个 repo，尤其当存在大量测试文件或废弃包时 - 确认 GOCACHE 可写：运行
go env GOCACHE，检查路径是否存在且当前用户有写权限；缓存不可写时，Go 会退化为每次全量编译
VS Code 里 gopls 总卡住，和编译速度有关吗？
有关，但不是编译慢导致卡，而是 gopls 启动时会主动触发一次完整模块加载 —— 如果 go.mod 里有坏掉的 replace、缺失的 require、或 go.sum 校验失败，它就会卡在“正在加载依赖”状态，连带拖慢代码跳转和补全。
立即学习“go语言免费学习笔记（深入）”；
- 先在终端跑
go mod verify，修复所有校验错误；再跑go mod tidy清理冗余依赖 - VS Code 设置里关掉
"go.useLanguageServer": true再开，强制重载 gopls；别依赖自动 reload - 如果项目含 cgo，确保
CGO_ENABLED=0（纯 Go 构建）或已安装对应 C 工具链；否则 gopls 会在后台反复尝试调用 gcc，造成假死
