CI/CD 中必须显式设置 GOOS=linux GOARCH=amd64（或 arm64）交叉编译，启用 CGO_ENABLED=0 实现静态链接，采用多阶段构建分离编译与运行环境，健康检查需区分 /live（进程存活）与 /ready（依赖就绪），镜像 tag 必须绑定 Git 提交哈希确保可追溯。
CI/CD 流水线里必须显式交叉编译
本地 macOS 或 Windows 上 go build 默认产出当前平台二进制，直接扔进 Linux Kubernetes 集群会报 cannot execute binary file: Exec format error。这不是环境变量问题，是架构不匹配的硬错误。
- CI 脚本中必须写死
GOOS=linux GOARCH=amd64（或arm64），不能依赖默认值 - 若服务需多架构支持，用并行构建：分别跑
GOOS=linux GOARCH=amd64 go build -o bin/service-amd64 ./cmd/api和GOOS=linux GOARCH=arm64 go build -o bin/service-arm64 ./cmd/api - 加
-ldflags="-s -w"可减小二进制体积 30%+，对镜像层大小和拉取速度有实际影响 -
CGO_ENABLED=0必须开启——否则静态链接失败， Alpine 或 distroless 镜像里一运行就报exec: "main": executable file not found in $PATH
Dockerfile 多阶段构建要分离构建与运行环境
把 golang:1.22 镜像直接当运行环境，会导致镜像体积膨胀 500MB+，还带一堆攻击面。真正上线的镜像只该包含可执行文件和必要 libc（甚至完全无 libc）。
- 第一阶段用
golang:1.22 AS builder下载依赖、编译；第二阶段用gcr.io/distroless/static-debian11或alpine:latest拷贝二进制 - 别在运行阶段
RUN apk add --no-cache ca-certificates——distroless 已内置，Alpine 则需加，但要确认基础镜像版本是否含证书更新 -
COPY --from=builder /app/main /后，CMD ["/main"]必须是绝对路径，否则容器启动失败 - 如果服务依赖动态库（如 SQLite 或某些 C 绑定），
CGO_ENABLED=0会编译失败，此时改用debian:slim并手动apt-get install依赖，而非 distroless
GitHub Actions 中健康检查端点必须区分 /live 与 /ready
Kubernetes 的 livenessProbe 和 readinessProbe 行为完全不同，共用一个 /healthz 会导致滚动更新卡住或误杀 Pod。
-
/live只检查进程存活（如能否响应 HTTP 200），不查 DB 连接、下游依赖等——它挂了就重启 Pod -
/ready必须检查 DB、Redis、关键下游服务是否就绪——它不通过，K8s 就不会把流量导进来 - CI 阶段测试时，
go test应模拟调用这两个端点，比如用http.Get("http://localhost:8080/live")和http.Get("http://localhost:8080/ready")，避免部署后才发现 probe 配置错位 - 在
kustomize的 base 中定义通用 probe 模板，在 overlay 中按环境覆盖 timeoutSeconds 或 initialDelaySeconds，别硬编码在 Deployment YAML 里
镜像 tag 和 K8s 部署必须绑定 Git 提交哈希
用 latest 当镜像 tag 是最常见回滚灾难源头；而每次 CI 都全量 kubectl apply 容易引发配置漂移，尤其当 ConfigMap 被人工修改过。
立即学习“go语言免费学习笔记（深入）”；
- 镜像 tag 固定用
${{ github.sha }}（GitHub Actions）或$CI_COMMIT_SHA（GitLab CI），确保每个构建产物唯一可追溯 - 部署阶段用
kubectl set image deployment/service-a api=${{ secrets.REGISTRY }}/service-a:${{ github.sha }}，只更新镜像字段，不动其他配置 - 如果用了
kustomize，在kustomization.yaml里用images:块替换镜像名，CI 中运行kustomize edit set image api=${{ secrets.REGISTRY }}/service-a:${{ github.sha }}再kubectl apply -k - 别在 Makefile 里写
docker push或kubectl命令——这些应由 CI 环境控制，Makefile 只负责构建和本地验证
