HTML无法实现真正的蓝绿切换，因其无路由控制权、不参与服务发现；真正的蓝绿依赖入口层（如Ingress、ALB）或服务网格的实时路由决策，前端仅能配合做健康检查标识、Header透传渲染、人工验证跳转等响应式适配。
蓝绿部署本身是后端基础设施层面的流量调度策略，HTML 页面无法直接实现蓝绿切换——它没有路由控制权、不参与服务发现、也不持有环境状态。所谓“HTML 蓝绿页面切换”，通常是前端配合后端蓝绿策略做的轻量级验证或降级兜底，比如在网关未切完、DNS 未生效、或需人工触发时，用一个静态页面手动跳转到蓝/绿环境地址。
为什么不能靠 HTML 实现真正的蓝绿切换
真正的蓝绿切换依赖的是：入口层（如 Ingress、Azure Front Door、ALB）或服务网格（如 Istio VirtualService）对请求的实时路由决策。HTML 是纯客户端资源，浏览器加载后就脱离服务端控制，无法修改 HTTP 请求目标、无法感知 Kubernetes Service 标签变化、也无法触发 DestinationRule 权重更新。
常见误解场景包括：
- 用
window.location.href跳转到https://green.example.com—— 这只是访问另一个域名，不是“切换”，且用户地址栏暴露、SEO 断裂、Cookie 隔离 - 在 HTML 中写两套 API 域名并用 JS 切换
fetch地址 —— 这绕过了网关统一鉴权、限流、灰度标透传，且前端逻辑泄露环境信息 - 用
iframe嵌入不同环境 —— 导致跨域限制、CSP 拦截、状态不同步、调试困难
HTML 可以安全配合蓝绿的三种方式
前端能做的，是「响应式适配」和「可控验证」，而非主导切换：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
健康检查页嵌入环境标识：在
/health或/status页面中，用document.body.dataset.env = "green"动态写入当前环境，供 QA 或监控脚本识别，避免人工误判 -
反向代理透传 Header 渲染 UI：Nginx 或 ALB 将
X-Env: green透传到 HTML 响应头，服务端模板（如 EJS、Thymeleaf）读取后渲染不同 logo、标题或 debug bar -
人工验证跳转页（仅限内网/测试环境）：提供一个带按钮的静态页，点击后跳转至
https://blue-api.example.com或https://green-api.example.com，但必须加醒目标识如<div class="env-badge">⚠️ 当前为 GREEN 环境（非生产）</div>
容易踩的坑：前端硬编码环境地址
很多团队在 config.js 里写死：
export const API_BASE = process.env.NODE_ENV === 'production' ? 'https://api-green.example.com' : 'https://api-blue.example.com';
这会导致：
- 构建产物绑定环境，一次构建无法复用蓝绿两套环境
- CI/CD 流水线必须打两个镜像，违背“一次构建、任意部署”原则
- 切流量时前端需重新发布，破坏蓝绿“零停机”前提
正确做法是：通过环境变量注入（如 nginx.conf 的 env API_BASE），或由后端在 HTML 中内联 window.APP_CONFIG = { apiBase: '/api' }，让所有 API 走相对路径，由网关统一做 /api → blue-api 或 /api → green-api 代理。
真正决定蓝绿成败的，永远是入口层配置是否原子、健康检查是否真实、数据库迁移是否可逆——HTML 页面最多是个观察窗，别让它变成单点故障源。
