github actions中golang ci卡住主因是go版本不匹配或模块代理未配置，需显式设go111module=on、goproxy=https://goproxy.cn,direct，并用actions/setup-go@v4指定版本；测试建议加-short避免超时；交叉编译须设cgo_enabled=0并chmod+x；多平台docker镜像需buildx；云部署应避免ssh，优先用ecs自动更新、wrangler发布或cloudflare tunnel。
用 GitHub Actions 实现 Golang 项目自动构建与测试
CI 阶段卡住，多半是因为 Go 版本不匹配或模块代理没配对。GitHub Actions 默认不启用 GO111MODULE，且国内拉取 golang.org/x/... 包大概率超时。
- 在
.github/workflows/ci.yml中显式设置GO111MODULE=on和GOPROXY=https://goproxy.cn,direct - 用
actions/setup-go@v4指定 Go 版本，避免依赖系统默认版本（比如 GitHub Runner 默认是 1.22，而你的go.mod写的是go 1.20） -
go test -race -v ./...建议加-short跳过耗时集成测试，否则 CI 容易超时
交叉编译二进制并上传到 GitHub Releases
Go 的交叉编译看似简单，但容易忽略 CGO 和静态链接问题——尤其当你部署到 Alpine 或无 libc 环境时，CGO_ENABLED=0 是必须项。
- 用
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -a -ldflags '-s -w' -o dist/myapp-linux-amd64 .生成精简可执行文件 - 上传前检查文件权限：
chmod +x dist/myapp-linux-amd64，否则 GitHub Releases 下载后无法直接运行 - 用
softprops/action-gh-release@v1上传时，确保files路径匹配 workflow 工作目录，常见错误是写成./dist/*却忘了run: cd dist && ls验证实际输出
用 Docker 构建多平台镜像并推送到 ECR 或 GHCR
本地 docker build 默认只构建当前架构镜像，而生产环境可能需要 arm64（比如 AWS Graviton）。直接用 buildx 是唯一靠谱方案，但必须提前启用并配置 builder 实例。
- 在 workflow 中加一步：
docker buildx create --use --name mybuilder --platform linux/amd64,linux/arm64 - Dockerfile 开头加
FROM --platform=linux/amd64 golang:1.22-alpine AS builder，避免构建阶段因平台不一致失败 - 推送到 ECR 前必须先
aws ecr get-login-password | docker login --username AWS --password-stdin xxx.dkr.ecr.us-east-1.amazonaws.com，且AWS_REGION环境变量不能漏
部署到云服务时绕过 SSH 手动操作
很多人把 “自动化部署” 理解为“用 Ansible 跑一遍”，结果还是得维护跳板机和密钥。真正省心的方式是让云服务直接拉取镜像或二进制，而非登录机器执行命令。
立即学习“go语言免费学习笔记（深入）”；
- AWS ECS：用 CodePipeline 触发 ECR 镜像更新后，ECS Service 自动滚动更新，无需 SSH
- Cloudflare Workers：用
wrangler pages deploy直接发布静态产物，Golang 后端改用wrangler pages project create+pages/functions注册 HTTP handler - GitHub Pages 不支持后端，但可以搭配 Cloudflare Tunnel 暴露本地
localhost:8080，适合临时验证或内部工具
最常被跳过的环节是健康检查路径配置——ECS 任务启动后立刻上报 healthy，但 Go 服务的 /healthz 可能还没监听成功，建议在 main 函数里加 http.ListenAndServe 前 sleep 100ms，或用 ECS 的 startTimeout 参数兜底。
