灰度发布本身不直接修改DOM，但新旧版本共存且JS逻辑未隔离时，旧DOM节点反复插入/移除会导致嵌套错乱、重复id、class污染；应通过服务端或CDN层按Cookie/URL参数返回对应版本HTML骨架，封装旧区块为自定义元素并校验id唯一性，禁用document.write和innerHTML整页注入，确保首屏HTML结构正确。
灰度发布时旧DOM残留导致HTML结构混乱
灰度发布本身不直接修改DOM，但若新旧版本共存、JS逻辑未隔离，旧DOM节点常被反复插入/移除，造成嵌套错乱、重复id、class污染。典型现象是页面出现双导航栏、按钮点击两次、表单提交失败——根源不是JS逻辑错，而是HTML结构在灰度切换中失去约束。
用自定义元素强制封装旧DOM片段
不要靠JS手动清理或重写innerHTML，那会放大风险。把旧版本核心区块（如header、product-list）封装成独立自定义元素，例如<legacy-header>，并在其connectedCallback里做一次性结构校验：
- 检查是否已存在同名
id，存在则自动加前缀（如id="nav-legacy-123"） - 禁止外部CSS通过全局选择器（如
div.header）穿透影响内部样式 - 在
disconnectedCallback里清空所有事件监听器，避免内存泄漏
这样即使灰度流量来回切换，DOM树节点仍保持原子性，不会因多次挂载产生结构撕裂。
静态资源加载阶段就阻断旧HTML污染
关键点在于：浏览器请求HTML和静态资源时，JS尚未执行，localStorage不可用，但Cookie和URL参数可用。所以必须在服务端或CDN层就决定返回哪套HTML骨架：
立即学习“前端免费学习笔记（深入）”；
- 后端模板渲染时，根据
Cookie: canary=on或URL ?v=1.1，直接输出对应版本的index.html，而非让前端JS动态替换整个body - 禁止前端用
document.write()或innerHTML = ...注入整页HTML——这会让旧DOM节点残留在父容器里，成为“幽灵节点” - 所有灰度分支的HTML必须满足W3C验证规则，尤其
id唯一性和aria-*属性完整性，可用html-validate在CI阶段校验
DOM diff前先做结构快照比对
Vue/React等框架的diff算法默认假设DOM结构稳定，但灰度场景下可能同时存在两套组件树。若发现document.getElementById("main")返回多个节点，说明HTML结构已失真。此时应：
- 在
mounted或useEffect里立即执行一次结构快照：document.querySelector('body').innerHTML.slice(0, 500)，与预设基准哈希比对 - 不匹配时触发降级：隐藏当前区域，显示
<legacy-fallback>并上报错误，而不是强行渲染 - 避免使用
key强制复用旧节点——灰度切换本质是版本切换，不是状态更新，key应包含版本标识，如:key="'header-v1.1'"
最易被忽略的是：灰度开关本身不该由前端JS控制初始HTML结构，而应在服务端响应头或CDN路由规则里完成分发。否则，哪怕DOM封装再严密，首屏HTML骨架错配，后续所有质量控制都建立在流沙之上。
