Go服务不实现蓝绿，只须“可探测、可中断、可隔离”：暴露真实/healthz或/readyz、正确配置readinessProbe、监听SIGTERM、打启动/关闭traceID；K8s原生蓝绿靠Service selector切标签，Argo Rollouts则通过CRD解耦控制，数据库与缓存需严格兼容。
Go 服务本身不实现蓝绿，只负责“能被切”
蓝绿部署不是 Go 程序里写个 switchTraffic() 就能跑起来的——它本质是基础设施层的流量调度行为。Go 应用唯一要做的，就是让自己“可探测、可中断、可隔离”。否则再好的 YAML 也切不过去。
- 必须暴露真实有效的
/healthz或/readyz：返回 200 不代表就绪，得检查数据库连通、依赖 gRPC 服务可达、本地缓存预热完成（如果必须） - 必须正确配置 Kubernetes
readinessProbe：超时时间timeoutSeconds别设成 1 秒，新 Pod 启动慢一点就直接被踢出 Endpoints - 必须监听
os.Interrupt和syscall.SIGTERM：K8s 发送终止信号后，得等正在处理的 HTTP 请求自然结束，不能立刻os.Exit(0) - 日志里打上启动/关闭 traceID：比如用
log.Printf("[startup] service %s ready, traceID=%s", env, traceID)，方便在 Loki 里快速比对蓝绿切换时刻的实例状态
常见错误现象：kubectl get rollout 卡在 Progressing，实际是 Go 的 readinessProbe 一直返回 503；或者切流后部分请求 502，其实是旧 Pod 已销毁但连接没断干净，缺优雅关闭逻辑。
Kubernetes 原生蓝绿：用 Service selector 切标签最直接
不用装 Argo Rollouts 也能做蓝绿，核心就两步：部署新版本 Deployment + 改 Service 的 selector。简单、可控、无额外组件依赖。
- 两个 Deployment 必须用不同镜像、相同 label 键（如
app: user-api），但加 version 区分：version: v1vsversion: v2 - Service 的
selector初始指向version: v1；验证 v2 就绪后，kubectl patch service user-api -p '{"spec":{"selector":{"version":"v2"}}}' - 别手动改 YAML 再 apply：容易覆盖 CI 流水线注入的 label，用 patch 或 kubectl set selector 更安全
- 提前给 v2 Pod 加
priorityClassName：避免集群资源紧张时，新副本被 OOMKilled 导致就绪失败
参数差异：minReadySeconds: 30 推荐设上，防止 Pod 虽然 ready 了但业务逻辑还没热起来（比如 Prometheus metrics 还没上报）；maxUnavailable: 0 在蓝绿场景下建议显式设为 0，避免滚动更新策略意外生效。
Argo Rollouts 蓝绿：YAML 驱动，Go 不用改一行代码
Argo Rollouts 是 CRD 控制器，和 Go 应用完全解耦。你写的 Go 代码连 rollout 这个词都不用出现，只要健康探针稳、label 对、metrics 可采，它就能工作。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 关键字段是
strategy.blueGreen.activeService和previewService：前者始终指向当前生产流量，后者指向待验证的新版本 -
autoPromotionEnabled: false生产环境务必关掉：切流前必须人工kubectl argo rollouts promote user-api确认，留出监控观察窗口 - previewService 的
selector必须和 v2 Pod 的 label 完全一致：一个拼写错误（比如app: mygo-apivsapp: my-go-api）就会导致 503，且kubectl describe service看不到明显报错 - Rollout 资源必须替代原 Deployment：删掉旧 Deployment，用
rollout类型声明，否则控制器不接管
性能影响：每次发布会保留 v1 和 v2 两套 ReplicaSet，内存/CPU 消耗翻倍；但 Go 进程自身零运行时开销——它只是被调度的对象，不是调度器。
数据库和状态兼容性：蓝绿最容易翻车的地方
蓝环境跑 v1、绿环境跑 v2，但它们很可能共用一套数据库。这时候接口可以不兼容，但数据结构和读写逻辑必须向前兼容。
- 数据库迁移必须“先加字段，再改逻辑，最后删字段”：v2 新增的非空字段必须带默认值，否则 v1 插入会失败
- 避免 v2 直接删 v1 正在用的索引或视图：即使你认为“v1 不需要了”，也要等蓝环境彻底下线后再操作
- 本地缓存（如
sync.Map或文件缓存）必须按环境隔离：用os.Getenv("ENVIRONMENT")做 key 前缀，否则 v1 读到 v2 写的脏数据 - 如果用了 Redis，建议蓝绿用不同 DB number 或不同 namespace：比如
v1:cache:user:123vsv2:cache:user:123
容易被忽略的一点：golang-migrate 的 migration 文件名带时间戳，但执行顺序依赖文件名排序。如果 v2 的迁移脚本里有 DROP COLUMN，而 v1 还在读这个字段，切流瞬间就会 panic——这种问题不会出现在日志里，只会出现在数据库 error log 中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
