HTML本身不支持灰度发布，实际是通过网关/Nginx路由、CDN边缘脚本或后端模板渲染等服务端能力，在HTML返回源头按用户属性分流，并配合带hash的资源路径与禁用HTML缓存来实现。
HTML 本身不支持灰度发布——它只是静态标记语言，没有运行时逻辑、用户分流或动态加载能力。所谓“HTML 灰度发布”，实际是前端资源（index.html 及其引用的 JS/CSS）在构建、部署、CDN 或网关层配合后端能力实现的流量分发策略。
为什么直接改 HTML 文件无法做灰度
浏览器一旦缓存了 index.html，就会长期复用；即使你替换了服务器上的文件，老用户可能还在用旧版 HTML 加载旧版 JS，导致行为错乱。常见错误现象包括：
- 用户 A 看到新按钮，但点击后调用的是旧 JS 里的函数（
handleClickV1），报ReferenceError - CDN 缓存了 HTML，强制刷新也拿不到新版本，灰度开关形同虚设
- 用 localStorage 写个“灰度标识”再
document.write加载不同 JS —— 这种写法在现代 HTML 中被浏览器拦截或导致 FOUC/白屏
真正可行的灰度入口：从 HTML 的加载源头控制
关键不是“怎么写 HTML”，而是“谁在什么时候把哪份 HTML 返回给谁”。实操路径有且仅有以下几种可靠方式：
-
网关/Nginx 层路由：根据请求头（如
Cookie: gray=on）、IP 段或 UA，将请求代理到不同静态资源目录，例如/v2/index.htmlvs/v1/index.html -
CDN 动态规则：Cloudflare Workers、阿里云 CDN 边缘脚本等，可在边缘判断用户属性，动态返回不同版本的 HTML 响应体（注意设置
Cache-Control: private避免缓存污染） -
后端模板渲染：如果你用 Node.js（Express/Nest）、Java（Spring Boot Thymeleaf）、PHP 等服务端渲染，直接在模板里注入不同版本的
scriptsrc，例如：<script src="/js/app.<%= version %>.min.js"></script>
，version 由后端按灰度策略计算
HTML 中必须配合的细节（否则灰度失效）
即使网关做了分流，HTML 自身若没约束，JS/CSS 仍可能跨版本混用。必须确保：
立即学习“前端免费学习笔记（深入）”；
- 所有外部资源（
script、link）使用带 hash 或版本号的 URL，例如/js/main.a1b2c3.js，禁止写/js/main.js这类无缓存区分的路径 - 禁用
index.html的强缓存：HTTP 响应头设为Cache-Control: no-cache, must-revalidate，或至少max-age=0；CDN 上对*.html关闭缓存或设极短 TTL - 避免在 HTML 里硬编码灰度逻辑（如
if (Math.random() > 0.1) loadV2()），这类客户端随机分流不可控、不可追溯、无法回滚
最容易被忽略的坑：HTML 里的相对路径和 base 标签
当你通过网关返回 /v2/index.html，但页面里写的是 <script src="bundle.js"></script>，浏览器会按当前 URL 路径解析为 /v2/bundle.js —— 如果你没同步部署对应 JS，就 404。解决方案只有两个：
- 统一用绝对路径：
<script src="/js/bundle.a1b2c3.js"></script>（推荐） - 加
<base href="/">到<head>，强制所有相对路径以根目录为基准（注意会影响图片、链接等所有相对 URL）
不处理这个，灰度一上线，半数用户白屏，而且错误监控里看不到明确报错，只看到大量 Failed to load resource。
