GitLab Runner必须显式指定Go镜像，因默认环境不含Go，直接go build会报command not found；应使用golang:1.22-alpine或golang:1.22镜像，且所有构建须设GOOS=linux GOARCH=amd64，并在test和build前执行go mod tidy -v确保依赖一致。
GitLab Runner 必须显式装 Go，不能靠系统自带
直接写 go build 却没声明镜像，90% 的流水线会卡在 command not found: go。GitLab Runner 默认是裸机或通用 Docker 容器，不带 Go 环境——哪怕你本地装了 1.22，CI 里照样报错。
- 用官方镜像最稳：
golang:1.22-alpine（轻量）或golang:1.22（含完整工具链，兼容性更好） - 别在
before_script里curl装 Go：网络抖动就失败，还拖慢构建；更别说 Alpine 上还得配apk add ca-certificates才能走代理 - 如果要用私有 registry 或内网镜像，确保镜像地址可拉取，且 Runner 有对应权限（比如配置了
DOCKER_AUTH_CONFIG）
GOOS/GOARCH 必须显式设，尤其跨平台编译
本地 macOS 开发，CI 构建却忘了设 GOOS=linux GOARCH=amd64，结果生成的二进制跑不进容器——这是最隐蔽也最常踩的坑。Go 编译默认继承宿主机平台，而生产容器全是 Linux。
- 所有
go build命令前加环境变量：GOOS=linux GOARCH=arm64 go build -o bin/app ./cmd/app - 若需多平台发布（比如同时支持
amd64和arm64），用make或 shell 循环，避免硬编码重复命令 - 注意
CGO_ENABLED=0：静态链接时必须关 CGO，否则镜像里缺 libc 就 panic；但若用了 SQLite 或某些 cgo 依赖，就得换golang:1.22非 Alpine 镜像
go mod tidy 是校验环节，不是可选项
跳过 go mod tidy -v，可能让 CI 成功但线上崩溃——因为 go.sum 被篡改或本地依赖未同步，导致模块版本不一致。
- 必须放在
test和build之前执行，且加上set -e：一行失败整 job 中断 - 搭配
go mod verify更保险，尤其在私有模块或 fork 项目中 - 缓存
GOMODCACHE能提速，但首次仍要跑tidy，否则缓存无效
多阶段 Docker 构建要拆清 build 与 runtime 环境
把 golang 镜像直接当最终运行镜像，等于白搭 Go 静态编译的优势——镜像体积大、攻击面宽、启动慢。
立即学习“go语言免费学习笔记（深入）”；
- Build 阶段用
golang:1.22编译，输出二进制到/app - Runtime 阶段用
scratch或distroless/static，只 COPY 二进制，不带 shell、包管理器、甚至 libc - Dockerfile 里写清楚
FROM --platform=linux/amd64，避免 ARM 主机上误构 AMD64 镜像
linux/arm64 镜像，Runner 必须是 ARM64 节点，或启用 docker buildx + QEMU 模拟，这点容易被忽略。 
