go编译本身不慢，瓶颈在于构建流程中的go list扫描、sum.golang.org校验、go:generate触发、cgo调用及误用-a/-i参数；加-mod=readonly、-trimpath、-o可显著提速。
Go 编译本身不慢，你等的那几秒，基本卡在构建流程里，不是编译器的问题。
go build -x 能暴露真瓶颈
执行 go build -x 会打印所有实际执行命令，别只看总耗时——拖慢你的往往不是 compile 阶段，而是前面几步：
-
go list扫描整个模块树：尤其含replace、本地路径或大量internal/包时，耗时飙升 - 校验
sum.golang.org：国内直连常 TLS 握手超时，单次卡 5–10 秒 -
go:generate无差别触发：改了个 handler，却重跑一遍 protobuf 生成 -
cgo启用后调用gcc/clang：完全脱离 Go 原生快车道 - 误用
-a或-i：Go 1.12+ 已废弃，强制全量重编，绕过缓存
三个必加参数：-mod=readonly -trimpath -o
不用改代码、不换工具，加这三个就能立竿见影：
-
-mod=readonly：禁止自动修改go.mod，避免go mod tidy误触发导致缓存失效 -
-trimpath：去掉编译路径信息，让相同源码在不同机器/路径下生成一致哈希，提升$GOCACHE复用率 -
-o指定输出路径：避免默认写入当前目录引发 I/O 竞争（尤其 SSD 有影响）
日常构建推荐组合：go build -mod=readonly -trimpath -o bin/app ./cmd/app
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
GOCACHE 失效的静默陷阱
$GOCACHE 默认开启，但很容易“看似有效实则失效”：
- 磁盘空间不足：
du -sh $(go env GOCACHE)查大小，满则缓存停用 - Docker 构建未挂载：
/root/.cache/go-build在 CI 中不持久化，每次都是新缓存 - 用
go run调试：go run默认绕过$GOCACHE，走临时目录；要走缓存得写成go build -o /tmp/a && /tmp/a - 混用
CGO_ENABLED=0和CGO_ENABLED=1：缓存完全不共享，哪怕其他参数一模一样
按需构建比全量扫更高效
90% 的日常修改只影响少数几个包。与其 go build ./ 全量扫，不如精准定位：
- 查变更包：
git status --porcelain | grep '\.go$' | xargs dirname | sort -u | xargs go list -f '{{.ImportPath}}' - 只构建这些包及其直接依赖：
go build $(上述命令) - 注意过滤
vendor/路径输出，否则可能漏掉主模块外的变更
这个方法在 monorepo 场景下特别有效，但要求模块边界清晰，否则容易漏依赖。
真正卡住构建的，从来不是 Go 编译器，而是你没意识到的那些“默认行为”——比如每次都要校验 sum、每次都要扫完整模块树、每次都要重跑 generate。调优不是堆参数，是关掉那些你不想要的默认动作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
