微服务CI/CD必须保留test、build、deploy三阶段：test需运行go test -race和go vet；build须静态编译（CGO_ENABLED=0）并设为artifacts；deploy应通过shell或k8s执行器调用kubectl/helm，而非直接推镜像。
golang 微服务的 CI/CD 流水线，不是“越全越好”，而是要匹配部署节奏、团队规模和基础设施约束。直接上完整流水线容易卡在数据库迁移失败、镜像推送超时或测试环境不可用上。
哪些阶段是微服务必须保留的？
对 golang 微服务来说，以下三个阶段不能省，其余可按需裁剪：
-
test：必须跑go test -race和go vet，并发问题在微服务间调用时才暴露，本地单测常漏掉 -
build：编译成静态二进制（CGO_ENABLED=0），避免容器运行时缺失 libc；产物必须设为artifacts供后续阶段复用 -
deploy：不是直接推镜像，而是用gitlab-runner的shell或kubernetes执行器，触发kubectl apply -f或helm upgrade
像 sast、coverage、release 这些阶段，初期建议注释掉——它们会拖慢流水线，且错误常来自配置而非代码。
.gitlab-ci.yml 中最易错的变量和缓存配置
很多流水线卡在 go mod download 超时或 go build 找不到依赖，根源是变量没对齐或缓存路径写错：
-
GO111MODULE=on必须全局设为on，否则go list ./...会跳过子模块 -
GOPROXY推荐用https://goproxy.cn,direct，别用proxy.golang.org（国内不稳定） - 缓存路径必须用项目内相对路径：
go/pkg/mod、go/bin、.cache/go-build—— 写成/go/pkg/mod就不生效 -
CI_REGISTRY_IMAGE如果用了私有 Registry，得手动拼接：$CI_REGISTRY/$CI_PROJECT_PATH，不能只靠CI_REGISTRY_IMAGE默认值
数据库迁移怎么安全集成进流水线？
用 golang-migrate/migrate 做自动迁移，但别让它和 deploy 阶段耦合——上线失败时回滚比迁移失败更难处理：
从 Git 仓库历史中彻底删除文件
下载
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- 迁移任务单独建一个
migratejob，stage: deploy，但加only: [main]限制只在主干触发 -
DATABASE_URL必须从 GitLab 的CI/CD Variables注入，绝不能硬编码在.gitlab-ci.yml里 - 命令用
./migrate -database "$DATABASE_URL" -path database/migrations up 1，而不是up全量——防止误执行未验证的迁移 - 加
allow_failure: true，让迁移失败不中断整个流水线（运维可人工介入）
迁移脚本本身要幂等：CREATE TABLE IF NOT EXISTS、ALTER TABLE ... ADD COLUMN IF NOT EXISTS 是底线。
Runner 标签和执行器选型的实际影响
微服务部署对 Runner 类型很敏感，选错会导致权限错误、Docker 命令失败或环境变量丢失：
- 用
docker执行器时，services: [docker:dind]必须配DOCKER_DRIVER=overlay2，否则docker build报failed to dial unix - 用
kubernetes执行器时，image必须带golang和kubectl（如bitnami/golang:1.23），别指望基础镜像自带 kubectl - 所有关键 job 都要加
tags: [golang]，否则 Runner 可能被其他语言项目抢走，导致go命令找不到 -
interruptible: true要开，尤其在频繁提交 PR 时，避免旧流水线占着资源不释放
最常被忽略的是 Runner 的 concurrent 设置——默认 1，意味着所有微服务共用一个构建槽位，一个服务卡住，整个交付链就停摆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
