go微服务ci/cd自动化关键在于构建产物可执行、镜像可复现、部署可回滚；必须显式设置goos=linux goarch=amd64（或arm64）交叉编译，禁用cgo，多阶段docker构建分离builder/runtime，规范镜像tag并区分/liveness与/ready探针。
Go微服务的CI/CD自动化，关键不在“能不能跑通”，而在于构建产物是否能在目标环境真正执行、镜像是否可复现、部署是否可回滚——这三点踩错一个，线上就容易出 exec format error 或 ImagePullBackOff。
GOOS 和 GOARCH 必须显式指定，否则二进制无法在 Linux 容器里运行
本地 macOS 或 Windows 上 go build 默认产出当前平台二进制，直接 COPY 进 Docker 镜像（基础镜像是 alpine 或 debian:slim）会报错：cannot execute binary file: Exec format error。
- CI 脚本中必须写全：
GOOS=linux GOARCH=amd64 go build -o bin/service ./cmd/service - 若需支持 ARM64（如 AWS Graviton 或树莓派集群），加一条并行构建：
GOOS=linux GOARCH=arm64 go build -o bin/service-arm64 ./cmd/service - 加
-ldflags="-s -w"可去掉调试符号，体积减少 30%+，对镜像层缓存和拉取速度有直接影响
Dockerfile 多阶段构建要分清 builder 和 runtime 阶段
常见错误是把 go 工具链留在最终镜像里，或 COPY 错了二进制路径，导致 exec: "main": executable file not found in $PATH。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- builder 阶段用
golang:1.21-alpine编译，runtime 阶段用alpine:latest或scratch - COPY 务必指定完整路径：
COPY --from=builder /workspace/bin/service /usr/local/bin/service，而不是COPY --from=builder ./bin/service . - 入口命令要写绝对路径：
ENTRYPOINT ["/usr/local/bin/service"]，避免 shell 解析失败
GitHub Actions 中 GOPROXY 和 Go module 版本易不一致
本地 go test 通过，CI 里失败，十有八九是模块依赖解析结果不同——尤其当项目用了私有模块或临时 replace。
- 在 workflow 中显式设置：
env: GOPROXY: https://proxy.golang.org,direct（或指向企业 proxy） - 加一步验证：
go mod download && go mod verify，早于go test执行 -
go test命令建议带-mod=readonly，防止 CI 环境意外修改go.mod
K8s 部署前必须分离 /live 和 /ready 探针端点
共用一个 /health 端点会导致滚动更新卡住：新 Pod 尚未加载配置或连接 DB，/ready 就已返回 200，K8s 提前切流，请求 500。
-
/live只检查进程存活（如 return 200），不涉及外部依赖 -
/ready必须校验数据库连接、下游服务连通性、配置加载状态等 - K8s YAML 中分别配置：
livenessProbe.httpGet.path: "/live"，readinessProbe.httpGet.path: "/ready"
最常被跳过的其实是镜像 tag 规范——用 git commit sha 当 tag 看似稳妥，但没做语义化版本 + 构建时间戳，就很难定位某次发布对应哪次代码变更，也难以快速回滚到“上一个稳定镜像”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
