Go多平台构建缓存完全隔离，GOOS/GOARCH变更即切换独立缓存命名空间；本地开发宜省略设置以复用宿主平台缓存，CI交叉编译须固定组合并确保环境干净。
Go 多平台构建缓存不会自动复用，GOOS/GOARCH 一变，$GOCACHE 就换一套流水线——不是缓存失效，是压根不进同一个缓存桶。
GOOS/GOARCH 变更导致构建缓存完全隔离
go build 时显式设置 GOOS=linux 或 GOARCH=arm64，会触发独立的编译缓存命名空间。即使源码、依赖、Go 版本全一样，$GOCACHE 里也存成不同哈希路径，彼此不可见。
- 本地开发建议不设
GOOS/GOARCH，让go build默认走宿主平台（如 macOS amd64），最大化复用已编译的.a文件 - CI 中必须交叉编译时，固定组合（如
GOOS=linux GOARCH=amd64），并确保环境变量干净：清除CGO_ENABLED等波动项，避免因环境差异导致缓存 key 变更 - 不要在 Makefile 或脚本里混用不同平台构建命令——一次
GOOS=windows go build就会污染当前 shell 下后续所有构建的缓存路径
如何验证多平台下 $GOCACHE 是否真正生效
不能只看 go env GOCACHE 输出路径存在，得确认 Go 进程有写权限且实际命中缓存。
- 执行
go build -x -o /dev/null ./cmd/myapp，观察输出中是否出现cd $GOCACHE和cache fill类日志；若大量显示compile [pkg]且无cache字样，说明缓存未被读取 - 检查
ls -la $(go env GOCACHE)，若目录为空或只有极少数子目录（00–ff十六进制前缀），大概率是权限问题或GOCACHE=off - Docker 构建中常见陷阱：
scratch镜像没创建/tmp/go-cache目录，或挂载卷权限为只读，导致go build回退到无缓存模式
模块缓存（GOMODCACHE）与构建缓存（GOCACHE）必须分开管理
二者职责完全不同，混淆会导致“以为缓存开了，其实一半没用上”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
GOMODCACHE存的是解压后的模块源码（如github.com/sirupsen/logrus@v1.9.3），影响go list、go mod download速度，但不加速编译本身 -
GOCACHE存的是编译中间产物（.a、语法树、测试快照等），直接影响go build和go test耗时 - CI 中若只缓存
$GOPATH/pkg/mod（即GOMODCACHE），却不缓存$GOCACHE，每次构建仍要重编所有包——必须两者都挂载或持久化 - 容器内推荐写法：
ENV GOCACHE=/tmp/go-cache GOMODCACHE=/tmp/go-modcache，并在ENTRYPOINT前mkdir -p /tmp/go-cache /tmp/go-modcache
构建参数和环境变量的组合陷阱
一个看似无害的标志，可能让整个缓存链路失效。
-
-race或-gcflags="-m"会强制重新编译所有依赖包，跳过$GOCACHE中的已有结果；仅限调试时临时加，切勿写死在构建脚本中 -
-ldflags="-X main.version=..."中的字符串值一旦变更（如时间戳、git commit），链接阶段无法复用缓存，应改用-buildmode=pie或将版本注入移到运行时 -
CGO_ENABLED=0能跳过 C 工具链、加快构建，但若项目实际用了net包的 DNS 解析（底层调 C），禁用后行为会变，需实测验证 - Go 1.21+ 支持
-buildmode=pie，但启用后链接耗时上升，且与-ldflags="-s -w"组合时需注意顺序——-s -w必须放在-buildmode后面才生效
最易被忽略的一点：缓存是否生效，不取决于你设了多少个环境变量，而取决于 go build 进程启动那一刻，它能不能往 $GOCACHE 目录里成功写入一个 .a 文件。权限、磁盘空间、路径是否存在，三者缺一不可。
