Go服务不实现蓝绿部署，仅需确保/readyz探针真实检查DB/Redis/gRPC等依赖并缓存结果，优雅关闭时用srv.Shutdown()配合ctx超时及后台goroutine响应ctx.Done()，蓝绿由K8s Service selector或Argo Rollouts控制。
Go 服务本身不“实现”蓝绿部署，它只负责让自己的就绪状态真实可信、关闭行为可预测；真正的蓝绿由 Kubernetes Service selector、Argo Rollouts 或 API 网关控制流量切换。
Go 服务必须暴露真实的 /readyz 接口
很多团队把 /health 写成固定返回 {"status": "up"}，结果新 Pod 还没连上数据库、Redis 连接池为空、gRPC client 没初始化完，K8s 就已把流量导过去，第一个请求直接 panic。
- 探针必须检查核心依赖：DB
Ping()、RedisSET test val EX 1、下游 gRPC 服务调用HealthCheck并判断状态为SERVING - 不要在 handler 里实时探测——改用后台 goroutine 定期刷新状态，
/readyz只读本地缓存布尔值 - K8s 中若
initialDelaySeconds: 5但服务实际启动要 8 秒，Pod 会被反复 kill；应配minReadySeconds: 10+ 启动后主动time.Sleep(2 * time.Second) - 更稳妥做法：定义
var ready = make(chan struct{})，所有初始化完成后close(ready)，/readyzhandler 阻塞等待该 channel
优雅关闭必须覆盖所有活跃连接与后台任务
切流后旧 Pod 收到 SIGTERM，但直接调 srv.Close() 或忽略信号，会导致正在处理的 HTTP 请求中断、gRPC 流式响应截断、消息队列消费丢失。
- HTTP server 必须用
srv.Shutdown(ctx)，且ctx带超时（建议10–30s），不能只用srv.Close() - 监听
os.Interrupt和syscall.SIGTERM，收到信号后先srv.Close()停 listener，再srv.Shutdown()等待 pending 请求 - 后台 goroutine（如 Kafka 消费、指标上报）必须接收
context.Context，并在ctx.Done()时退出；别用全局 flag 或无缓冲 channel 控制停止 - K8s
preStopHook里加sleep 15是掩盖问题，本质是 shutdown 逻辑没覆盖全
Kubernetes 中蓝绿靠 Service selector 切换，不是靠 Go 代码
你不需要在 main.go 里写函数触发“切换”，而是通过两个 Deployment（v1 和 v2）+ 两个 Service（blue-svc 和 green-svc）+ 一个主 Service（app-svc）来实现。主 Service 的 selector 指向哪套 label，流量就去哪边。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 蓝绿环境的 Pod 必须带不同 label，例如
env: bluevsenv: green；主 Service 的selector动态更新即可 - Argo Rollouts 更进一步：用
RolloutCRD 替代 Deployment，配置strategy: blueGreen，指定activeService和previewService - 常见错误：
previewService的 selector 与新版本 Pod label 不匹配（比如app: mygo-apivsapp: my-go-api），导致切流后 503 - 本地模拟可用
gvm+ 不同端口（如:8080和:8081）+ Nginx upstream 手动改配置，但仅限验证逻辑
配置与状态必须严格分离，避免蓝绿行为不一致
同一个二进制在蓝/绿环境跑出不同行为，通常是因为硬编码了环境相关逻辑，或依赖未隔离的共享资源。
- 数据库连接字符串、Redis 地址、下游服务 endpoint 必须通过环境变量或 ConfigMap 注入，禁止写死在代码里
- 如果用缓存，蓝/绿环境必须用不同 key 前缀（如
blue:user:123vsgreen:user:123），否则预热冲突或脏读 - 日志路径、监控上报 endpoint、trace sampler 率也要按
ENVIRONMENT变量区分，方便定位问题归属 - HTTP server 端口本身不用区分（K8s Service 抽象掉了），但本地调试时两个实例不能绑定同一端口，需显式传参或读环境变量
最容易被忽略的是：就绪检查和优雅关闭之间存在竞态窗口——比如 DB 初始化刚完成，/readyz 返回 true，但 Redis 连接池还没 warm up；或者 shutdown 时 HTTP 连接已关闭，但后台 goroutine 还在往 Kafka 发送消息。这些都得靠具体依赖的真实状态驱动，而不是靠 sleep 或计数器模拟。
