Go项目CI/CD无需额外安装Go运行时，主流平台默认已预装；关键在环境隔离、依赖缓存（用actions/cache缓存$HOME/go/pkg/mod，key含go.sum哈希）、竞态检测（CI必须启用-race）、交叉编译配置（CGO_ENABLED=0适配静态链接，cgo需对应C工具链）及覆盖率上传（正确生成、合并、转换coverage.out）。
Go 项目做 CI/CD 不需要额外装 Go 运行时 —— 大多数主流 CI 平台（GitHub Actions、GitLab CI、CircleCI）的默认 Linux runner 已预装 Go，且版本通常较新。真正要花精力的是环境隔离、依赖缓存、交叉编译控制和测试覆盖率上传这几个环节。
如何在 GitHub Actions 中复用 Go 缓存避免重复下载 module
Go 的 go mod download 在每次 job 启动时都会重拉所有依赖，拖慢构建。必须显式启用 actions/cache 缓存 $HOME/go/pkg/mod 目录，并用 go mod download 生成精确的缓存 key。
- 缓存 key 必须包含
go.sum的哈希值，否则go.mod小改就会命中旧缓存，导致构建不一致 - 推荐写法：
key: cache-go-mod-${{ hashFiles('**/go.sum') }} - 务必在
go build前执行go mod download，否则缓存不会生效 - 不要缓存
$HOME/go整个目录，它含 GOPATH 构建产物，易污染后续 job
为什么 go test -race 在 CI 中常失败而本地不报错
竞态检测器（race detector）对调度敏感，CI 环境 CPU 资源受限、调度更随机，更容易暴露隐藏的 data race。本地跑过不等于线程安全。
- CI 中必须固定启用
-race，不能只在本地跑 - 避免在测试中用
time.Sleep模拟等待 —— race detector 会忽略 sleep，但实际仍可能竞争 - 若使用
sync.WaitGroup，确保Wait()调用在所有Add()之后，且无 goroutine 泄漏 - 某些第三方库（如旧版
golang.org/x/net/http2）自带竞态，需升到 v0.18.0+ 或打 patch
交叉编译时 CGO_ENABLED=0 和 GOOS=linux GOARCH=arm64 怎么配才不出错
纯静态二进制（CGO_ENABLED=0）能免去 libc 依赖，适合容器部署；但一旦用了 cgo（如 sqlite、openssl），就必须关掉该选项并确保目标平台有对应 C toolchain。
立即学习“go语言免费学习笔记（深入）”；
- 镜像选择：用
golang:1.22-alpine无法启用 cgo（musl libc 不兼容），应选golang:1.22-slim或debian:bookworm-slim - 交叉编译前必须设
CC_arm64=arm64-linux-gnu-gcc（或安装gcc-aarch64-linux-gnu） - 若项目含 cgo 且需多平台输出，建议用
docker buildx构建，而非单纯靠GOOS/GOARCH -
CGO_ENABLED=0下net包 DNS 解析会 fallback 到 Go 自实现（非 libc），可能影响内网 DNS 配置行为
上传测试覆盖率到 Coveralls / Codecov 为什么总显示 0%
根本原因通常是 go test -coverprofile 输出路径未被正确读取，或 profile 文件没被合并（多包测试时）。
- 必须用
go test ./... -covermode=count -coverprofile=coverage.out，不能省略./...，否则只测当前目录 - 多个包并行测试时，
go test不自动合并 profile，要用gocovmerge或gotestsum合并多个.out文件 - Codecov 的 bash uploader 默认找
coverage.txt，需用go tool cover -func=coverage.out > coverage.txt转换格式 - GitHub Actions 中注意工作目录：若 checkout 后
cd过，coverage.out路径可能错位，建议用绝对路径写入
CI 脚本里最容易被忽略的是模块校验与构建一致性：每次 go build 前加一句 go mod verify，能提前发现被篡改的依赖；而用 go list -m all 输出版本快照存为 artifact，比单看 go.mod 更可靠。
