交叉编译时GOOS/GOARCH会彻底绕过本地构建缓存，每次设置都会触发全新编译流水线；日常开发应省略二者以复用缓存，CI中则需固定组合并清理CGO_ENABLED等无关变量。
交叉编译时GOOS/GOARCH会彻底绕过本地构建缓存
每次设置 GOOS 或 GOARCH，go build 就会认为这是全新目标平台，强制重新编译所有依赖包——哪怕你刚在本地构建过一次。这不是 bug，是设计行为。
实操建议：
- 日常开发尽量不设
GOOS/GOARCH，只用宿主平台构建（比如你在 Linux 上就直接go build ./cmd/app），让缓存真正起作用 - CI 中必须交叉编译时，固定组合（如
GOOS=linux GOARCH=arm64），并显式清理无关变量：CGO_ENABLED=0 GOPROXY=https://goproxy.cn GOSUMDB=sum.golang.org - 避免在脚本里混用不同
GOOS/GOARCH组合，否则每个组合都会生成独立缓存副本，浪费磁盘且拖慢后续构建
CGO_ENABLED=0 不只是“禁用 C”，而是跳过整个 C 工具链
只要项目没硬依赖 C 库（比如没调用 net 包的 cgo DNS 解析、没用 sqlite3 或 openssl 的 cgo binding），就该默认关掉 cgo。它带来的提速不是“快一点”，而是“快一倍以上”——因为完全避开了 gcc/clang 调用、头文件扫描、中间对象生成等环节。
注意点：
-
CGO_ENABLED=0下net包会自动切到纯 Go DNS 解析器，行为一致但无额外依赖 - 若用了
cgo相关构建标签（如// +build cgo），关掉后对应代码会被忽略，需提前验证逻辑覆盖 - Docker 多阶段构建中，在 builder 阶段也应设
CGO_ENABLED=0，否则缓存无法跨阶段复用
模块代理和校验耗时经常比编译本身还长
执行 go build -x 会暴露真实瓶颈：常卡在 go list -m 查询或 sum.golang.org 校验上，尤其国内直连时单次 TLS 握手可能卡 5–10 秒。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
必须做的配置：
- 设
GOPROXY=https://goproxy.cn,direct（不要漏掉,directfallback） - 关掉校验（仅限可信内网环境）：
GOSUMDB=off；否则至少用GOSUMDB=sum.golang.google.cn替代默认地址 - 避免
replace指向本地路径（如replace example.com => ./local/example），它会让 go 工具每次重新 hash 和编译该模块，彻底破坏缓存
多平台构建别用 air/reflex 这类热重载工具
它们本质是包装 go build 并监听文件变化，但对多平台场景毫无优化能力——改一行代码，照样触发全量 go generate + 所有 GOOS/GOARCH 组合重编。
更可控的做法：
- 用
make或just写明确目标，例如：make build-linux-amd64只跑一次构建，不连带其他平台 - CI 中并行执行多个
go build，共享同一轮go mod download结果（先统一拉依赖，再分平台编译） - 如果真要热重载，让 air 只监听
.go文件，并把命令绑定为make dev-local，而不是让它自己瞎猜
真正的瓶颈往往不在 Go 编译器，而在你每次构建时都重复做的网络请求、C 工具链调用和缓存隔离。固定环境变量、砍掉 cgo、换掉代理、管住热重载工具——这四件事做完，多平台构建速度通常能回落到“改完保存，2 秒内看到结果”的水平。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
