最简可用Go CI流程需用actions/setup-go配置Go环境并显式启用GO111MODULE=on；必须先checkout再setup-go；含cgo需设CGO_ENABLED=1；避免冗余go mod download；交叉编译需指定GOOS/GOARCH；发布需permissions: contents: write及正确标签引用。
Go 项目用 GitHub Actions 做 CI 是稳妥且主流的选择，只要注意 go 版本、模块路径和测试环境的一致性，基本不会翻车。
如何配置最简可用的 Go CI 流程
核心是用官方 actions/setup-go 设置 Go 环境，并确保 GO111MODULE=on 开启（Go 1.16+ 默认开启，但显式声明更安全）。工作目录默认就是仓库根，无需额外 cd。
name: Go CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: '1.22'
- name: Run tests
run: go test -v -race ./...
- name: Build binaries
run: go build -o ./bin/app ./cmd/app-
actions/checkout@v4必须放在setup-go之前，否则go mod找不到go.sum - 如果项目含 cgo 依赖（如
net包在某些系统下触发），需加env: CGO_ENABLED: "1" -
go test -v -race ./...覆盖全部子包，但若含集成测试（依赖 DB/HTTP），建议单独拆出 job 并跳过-race
为什么 go mod download 经常被误加
多数人以为要显式下载依赖，其实 go test 或 go build 会自动触发 go mod download。手动加这步不仅冗余，还可能因缓存导致本地与 CI 行为不一致。
- CI 中
go mod download只在需要预热模块缓存（如私有 registry）时才有意义 - 若你用了
actions/cache@v4缓存~/.cache/go-build和~/go/pkg/mod，那go mod download更没必要 - 错误示范：
run: go mod download && go test ./...—— 多余且掩盖真实依赖问题
交叉编译和发布 binary 到 GitHub Release 的关键点
Go 本身支持跨平台构建，但 GitHub Actions 的 runner 是 Linux，想生成 macOS/Windows 二进制得靠 GOOS/GOARCH 显式控制；发布则依赖 softprops/action-gh-release@v1，且 token 权限必须足够。
立即学习“go语言免费学习笔记（深入）”；
-
GOOS=darwin GOARCH=arm64 go build -o app-darwin-arm64生成 macOS ARM64 二进制 - 发布前确保 workflow 使用
permissions:显式授权：contents: write（否则action-gh-release会静默失败） - 标签名必须匹配
github.ref：比如refs/tags/v1.0.0触发时，github.event.head_commit.tag不可靠，应直接用${{ github.head_ref }}或${{ github.ref_name }}
最容易被忽略的是 go.work 文件的存在——如果你项目用了 Go Workspaces，CI 默认不识别，必须加 run: go work sync 同步依赖，否则 go test 会报 no required module provides package。
