Go服务不实现蓝绿部署，只负责“准备好被切换”：暴露真实就绪状态（探测核心依赖并缓存结果）、扛住中断信号、不抢流量；需避免初始化竞态，确保依赖就绪后才开放流量。
Go 服务本身不实现蓝绿部署，它只负责“准备好被切换”——这是最常被误解的前提。蓝绿不是你在 main.go 里调用某个函数触发的流程，而是由 Kubernetes、Argo Rollouts 或 API 网关控制的基础设施行为。Go 应用要做的，只有三件事：暴露真实就绪状态、扛住中断信号、不抢流量。
就绪探针必须检查依赖，不能只返回 {"status": "up"}
很多团队把 /readyz 写成硬编码返回 HTTP 200，结果新 Pod 还没连上数据库、gRPC client 没初始化完，K8s 就已把它加进 Service endpoints，第一个请求直接 panic。
- 必须同步或异步探测核心依赖：PostgreSQL 连接池是否 ready、Redis 是否可写、下游 gRPC 服务的
/health是否返回SERVING - 避免在 handler 中实时执行耗时检查；推荐启动时起 goroutine 定期探测，用本地变量缓存结果，
/readyz只读缓存 - 若初始化耗时 8 秒，但
initialDelaySeconds: 5，K8s 会在 probe 失败 3 次后 kill Pod；应设initialDelaySeconds: 10+periodSeconds: 5+failureThreshold: 3 - 更稳妥的做法是定义一个
readyCh chan struct{}，所有初始化完成后close(readyCh)，/readyzhandler 阻塞等待该 channel
启动后延迟开放就绪，别急着抢流量
Go 的并发初始化容易掩盖竞态：比如配置加载和 DB 初始化顺序错乱，导致 /readyz 返回 200 时，实际 DB client 还是 nil。
- HTTP server 启动后加
time.Sleep(2 * time.Second)是最低成本缓冲，但不推荐长期依赖 - 真正可靠的方案是：所有初始化逻辑（DB、Redis、gRPC、配置校验）完成后，再 close
readyCh；/readyzhandler 用select { case - 不要把
livenessProbe和readinessProbe混用：前者用于判断进程是否存活（如 goroutine 泄漏），后者才决定是否导流；livenessProbe耗时超过timeoutSeconds会触发重启
优雅关闭必须覆盖所有活跃连接与后台任务
蓝绿切换后旧版本下线，如果只调 srv.Close() 或忽略信号，正在处理的 HTTP 请求、gRPC 流、消息消费 goroutine 都会被粗暴中断。
立即学习“go语言免费学习笔记（深入）”；
- 必须监听
os.Interrupt和syscall.SIGTERM，收到后先调srv.Shutdown(ctx)，ctx 带 10–30 秒超时 - 所有后台 goroutine（如 metrics 上报、kafka 消费）需接收
context.Context，并在ctx.Done()时主动退出；禁用无缓冲 channel 或全局 flag 控制停止 - K8s
preStopHook里写sleep 15是掩盖问题，不是解决方案；shutdown 逻辑必须覆盖全部生命周期 - 日志中记录 shutdown 开始/结束时间，并带上 traceID，方便排查某次切换是否因 pending 请求超时失败
Service selector 切换或 Rollout 配置失败，90% 是 label 不匹配
在 Kubernetes 原生蓝绿中，你靠修改 Service 的 selector 把流量从 version: v1 切到 version: v2；用 Argo Rollouts 则靠 activeService 和 previewService 的 selector 指向不同 ReplicaSet。一旦失败，现象就是 503 或 kubectl get rollout 卡在 Progressing。
- 检查新 Deployment 的 Pod label 是否真包含
app: my-go-api（注意连字符、大小写、空格）；常见错误是 Dockerfile 构建时APP_VERSION=v2但 label 写成app: mygoapi - 确认新 Pod 的
readinessProbe已通过：kubectl get pods -l version=v2+kubectl describe pod <name></name>查 Events - Argo Rollouts 中，
previewService的 selector 必须和新 Pod label 完全一致；autoPromotionEnabled: false适合生产，避免自动切流引发事故 - 本地模拟可用
gvm启两个进程，分别监听:8080和:8081，用 Nginx upstream 切换；但仅限验证逻辑，不可替代 K8s 真实探针行为
最容易被忽略的是：健康检查的真实性和 shutdown 的完整性，这两点不达标，再复杂的 Rollout YAML 或网关规则都只是纸面流程。K8s 不关心你用了什么框架，只认 probe 返回码和 signal 响应动作。
