判断html结构跨浏览器一致性需先用w3c validator修复非法html，再通过存原始结构并克隆获取纯净dom副本，因其跳过各引擎解析纠错差异；禁用innerhtml注入、避免省略标签与错误嵌套，并仅断言节点类型、属性、层级等结构信息。
怎么判断HTML结构在Chrome/Firefox/Safari里真的一致
直接用 document.querySelectorAll 断言节点数量或层级，大概率失败——不是代码写错了，是浏览器对非法 HTML 的“纠错”逻辑不同。比如 <div><p>text</p></div>（<p></p> 没闭合），Chrome 会补
<div>，Safari 可能丢弃整个 <code><p></p>，Firefox 甚至拒绝插入。结果 document.querySelectorAll('p').length 在三端返回值完全不同。
真正可靠的判断方式只有两个：
- 先用 W3C Validator 验证 HTML 字符串，修复所有 “End tag for element X implied” 类警告；
- 测试时不用
innerHTML = htmlStr注入，改用<template></template>存原始结构，再通过template.content.cloneNode(true)获取纯净 DOM 副本——这个副本在所有引擎中完全一致。
为什么<template></template>是唯一绕过解析差异的原生方案
<template></template> 不渲染、不执行脚本、不加载资源，只存原始字符串。它跳过了浏览器实时解析阶段，也就避开了各引擎对省略标签（如 <tbody>）、嵌套错误（如 <code><p></p> 里放 <div>）的容错处理分歧。
<p>实操要点：</p>
<ul><li>表格结构必须显式写出 <code><tbody></tbody>，哪怕为空；JS 渲染逻辑只操作该节点，不碰 <table> 直接子节点；
<li>克隆后调用 <code>el.normalize() 合并相邻文本节点，避免换行/空格被不同引擎拆成不同数量的 Text 节点；
<template></template> 里写内联事件处理器（如 onclick），它们克隆后不会自动绑定；dataset，统一用 getAttribute('data-xxx') 读取自定义属性。哪些 HTML 写法会立刻触发跨引擎结构分裂
不是所有“合法但松散”的写法都安全。以下写法在多引擎下极易导致 DOM 树结构不一致：
-
<table><tr><td>cell</td></tr></table>—— 缺失<tbody>，Chrome 自动包裹，Firefox 可能挂到 <code><table> 下，Safari 渲染时丢节点； <li> <code><p><section>content</section></p>——<p></p>不允许含块级元素，各引擎纠错策略不同，querySelectorAll('section')结果不可预测； -
<main><p>text</p></main>—— 若没加main { display: block }，IE8–9 不创建节点，Safari 曾当 inline 处理； 前有 BOM、空格或注释 —— IE/Edge Legacy 直接切怪异模式，盒模型、浮动、<code>vertical-align全部失效。- Safari 14–15 对
display: flex子项的min-width计算有 bug，但这是布局阶段问题，不影响 DOM 结构本身； - 若测试中顺带检查
el.offsetWidth，就会在 Safari 上拿到错误值，误判为“结构异常”； - 验证样式是否生效，应读
window.getComputedStyle(el).minWidth，而非依赖 JS 动态设el.style.minWidth = '0'—— Safari 可能在计算前已完成错误布局。
结构一致性 ≠ 渲染一致性，别混用 layout 属性做断言
结构测试只比对节点类型、属性、层级、文本内容。一旦读取 offsetWidth、getBoundingClientRect() 或 clientHeight，就掉进渲染阶段陷阱。
典型误判场景：
真正要测结构，就只碰 nodeType、nodeName、attributes、textContent 和 children.length。其余全算渲染层，得另起一套视觉回归测试。
