结论：三者都是减少发布风险的策略：滚动更新逐批替换实例（省资源、过程渐进）；蓝绿部署维护两套环境整体切换（回滚快、资源翻倍）；金丝雀发布先放小流量验证新版本再逐步放大（风险最小、实现最复杂）。

展开：滚动更新是 K8s Deployment 默认策略，maxSurge/maxUnavailable 控制新旧版本并存比例，优点是资源开销小，缺点是发布期间新旧版本混合，要求版本间 API 和数据 schema 双向兼容。蓝绿部署同时运行蓝（旧）绿（新）两套完整环境，流量通过 LB/Ingress 一次性切换，回滚就是切回来，秒级完成；代价是双倍资源，且数据库变更必须向前兼容（否则切回旧版本读不懂新数据）。金丝雀发布先给 1%-5% 流量，观测错误率、延迟等核心指标，达标后阶梯放大到 100%，K8s 原生可用两组 Deployment 按比例调副本实现粗粒度分流，精细分流（按 Header、权重）要 Istio/Argo Rollouts/Flagger，进阶是自动金丝雀分析——指标异常自动回滚。选型建议：内部低风险服务滚动更新即可；核心交易链路用金丝雀；要求秒级回滚且资源充足用蓝绿。共同前提：数据库变更用扩展-收缩（expand-contract）模式分步发布，这是发布策略面试的高频追问。