go项目ci/cd核心卡点是环境一致性、模块可信性、产物可控性；需提交go.mod/go.sum、执行go mod tidy -v、禁用gosumdb=off、显式配置goproxy/gocache、限定go test路径并加-race和-coverage、硬编码go build输出路径及-ldflags、显式设置交叉编译goos/goarch。
Go 项目跑 CI/CD 不是“配个 YAML 就完事”，核心卡点在环境一致性、模块可信性、产物可控性这三处。本地能 go build 成功，CI 里报 undefined: http.HandleFunc 或 module lookup failed，基本都栽在这儿。
go.mod 和 go.sum 必须一起提交，且每次 PR 前要 go mod tidy -v
CI 环境是干净容器，没有本地缓存、不继承 GOPATH、也不自动 resolve 间接依赖。不提交 go.sum，go build 会重新解析整个依赖树，可能拉到带 break change 的次版本；不运行 go mod tidy，go.mod 可能残留已删代码引用的模块，导致构建 panic。
-
go.sum不能被.gitignore，不能只留本地 - PR 提交前必须执行
go mod tidy -v，检查输出是否新增/删减模块 - 禁止在 workflow 中加
GOSUMDB=off—— 这等于主动绕过校验，放弃供应链安全底线
GitHub Actions 里必须显式设 GOPROXY 和 GOCACHE
默认 GOPROXY=https://proxy.golang.org,direct，国内直连大概率超时；不设 GOCACHE 会导致每次重编标准库，白耗 30 秒以上。
- 推荐写法：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOCACHE=/tmp/gocache - 别依赖基础镜像自带设置 ——
golang:1.21和golang:alpine默认值可能不同 - GitLab CI 可在
.gitlab-ci.yml全局variables里定义GOCACHE: "$CI_PROJECT_DIR/.gocache"，再用cache:持久化
go test 要限定路径、加 -race、导出 coverage.txt
用 go test ./ 扫全目录，会误含 vendor/ 或 examples/ 下的无效测试；不加 -race 就错过竞态问题；不生成 coverage.txt，覆盖率就只是个数字，没法卡门禁。
- 推荐写法：
go test -v -race -timeout 30s -coverprofile=coverage.txt -covermode=count ./pkg/ ./cmd/ -
-covermode=count是原子模式，适合并发测试统计 - CI 工具（如 Codecov、GitLab coverage regex）全靠解析该文件或 stdout，没它就无法做阈值校验
go build 输出必须硬编码路径和 -ldflags
不指定 -o，二进制默认丢当前目录，后续步骤无法定位；不用 -ldflags="-s -w"，二进制体积翻倍、还暴露内部路径和调试符号。
- 统一用：
go build -o ./bin/myapp -ldflags="-s -w" ./cmd/myapp - 交叉编译必须显式设
GOOS/GOARCH，例如：GOOS=linux GOARCH=arm64 go build -o ./bin/myapp-linux-arm64 ./cmd/myapp - 编译后记得
chmod +x ./bin/myapp（尤其 macOS/Linux 产物）
最易被忽略的是：所有这些配置不是孤立生效的。比如你缓存了 go.sum，但没提交它，缓存就失效；你加了 -race，但没限定测试路径，某个 example 里的死循环就把 job 卡超时了。CI 的稳定性，本质是把本地开发的隐式约定，全部变成 workflow 里的显式声明。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
