直接回答：前端灰度的本质是“入口 HTML 与静态资源分离发布”：JS/CSS 带内容哈希发到 CDN 永久缓存、不可变；HTML（或 SSR 的模板引用）不缓存、指向哪批资源由它决定。灰度就是按规则（用户 ID 哈希、白名单、比例）决定返回指向旧版还是新版资源的 HTML；回滚就是把 HTML 指回旧资源——秒级完成，因为旧资源在 CDN 上从未被覆盖。
展开解析：实现要点：构建产物按版本目录存放（/static/v123/），HTML 由服务端模板或边缘函数动态拼装资源清单，灰度规则放在配置中心实时可调；比例灰度用稳定哈希（同一用户始终进同一桶），避免页面间资源版本错乱。资源兼容性是最大陷阱：新版 JS 与旧版 API 的契约、LocalStorage 里旧版写的数据结构、Service Worker 缓存的旧资源——都要么前后兼容要么随灰度策略隔离。观测配套：错误监控按版本 tag 维度看板（Sentry release），新版错误率或 Web Vitals 显著恶化自动告警甚至自动切回。微前端场景主子应用各自有版本，灰度矩阵复杂度指数上升，建议统一发布台账。 SSR 站点还要考虑边缘缓存里的旧 HTML 残留，切换后主动 purge 或给 HTML 短 TTL。一句话总结：前端回滚快是因为从不“覆盖发布”，这个纪律比任何工具都重要。
追问方向：灰度期间新旧版本共享的接口如何兼容？Service Worker 缓存如何随版本失效？
（约 470 字）