嵌套超过6层会触发dom截断，chrome和safari解析html时对深度有限制，depth>6的节点可能被跳过，导致queryselector失效；需用devtools查depth字段并拆解结构。
嵌套超过6层会触发DOM截断
Chrome 和 Safari 在解析 HTML 时，对嵌套深度有隐式限制。实测中，一旦某节点的 node.depth（可通过 DevTools → Elements → 右键节点 → “Show DOM properties” 查看）超过 6，后续标签可能被跳过——你写的 <footer></footer> 或 <aside></aside> 根本不进 DOM 树，document.querySelector('footer') 返回 null，连 JS 都救不回来。
- 典型高危结构：
<div><div><div><table><tr><td><div><p>内容</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher"><img src="https://img.php.cn/upload/skill/000/000/081/179109368394970.jpg" alt="Wechat HTML Publisher" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="overflowclass">Wechat HTML Publisher</a> <p class="overflowclass">直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。</p> </div> <a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div></div></td></tr></table></div></div></div>——<td> 内再套 <code><div> 是重灾区，样式重排开销翻倍 <li>移动端或低端安卓设备上，5 层嵌套就可能让首次内容绘制（FCP）延迟 20–50ms</li> <li>Vue/React SSR 输出常自带冗余根节点（如每个组件包一层 <code><div>），需检查构建产物，开启 <code>Fragment或使用v-for的:key直接渲染子元素用语义化标签替代
堆叠不等于“改个名字”把
<div class="header"> 换成 <code><header></header>不只是语义提升，它直接减少浏览器创建中间节点的开销——<header></header>、<section></section>、<nav></nav>等原生标签在现代引擎中有更轻量的内部表示，且 CSS 选择器也更高效（比如header h1比.wrapper .inner .header h1少两次匹配）。- 别为了“看起来像语义化”而硬套：一个纯装饰性图标容器，用
<div> 比乱用 <code><figure></figure>更合理 <table> 里禁止出现 <code><div> —— 表格单元格内嵌套会强制触发额外布局计算，尤其当配合 <code>display: table-cell的伪表格时- 能用
display: flex或display: grid实现的布局，就别靠三层<div> + float 清除来凑；例如三栏布局，直接让 <code><main></main>设grid-template-columns，子元素用<section></section>即可script位置不当会让HTML“半途而废”
没加
defer或async的<script></script>放在或开头，浏览器必须暂停 HTML 解析、下载并执行完脚本，才能继续构建 DOM。这不是“慢一点”，而是首屏白屏的确定性原因。- 非关键脚本（统计、埋点、第三方 SDK）一律加
defer：按顺序下载+执行，不阻塞解析 - 纯交互逻辑（如按钮点击绑定）可用
async，但注意它可能在DOMContentLoaded前执行，document.body还没就绪 - 真要操作 DOM 的脚本，放
前——别信“DOMContentLoaded比load快”的模糊说法，实测晚 100ms 加载，首屏就晚 100ms - 内联大段 JS（如模板字符串拼接）慎用：
innerHTML = '<div>...</div>'解析比document.createElement慢 3–5 倍
检查和验证嵌套深度的实操路径
不能靠肉眼数
<div>，得用工具确认真实 DOM 深度。DevTools 提供的属性查看方式最可靠，且不依赖框架抽象层。 <ul> <li>打开 Chrome DevTools → Elements 面板 → 右键任意节点 → “Show DOM properties” → 找 <code>depth字段 - 非关键脚本（统计、埋点、第三方 SDK）一律加
- 若发现某区域普遍 ≥6，优先拆解：把长列表用多个
<section></section>分块，每块子元素控制在 50 个以内 - 服务端渲染项目，检查输出 HTML 源码（右键 → “View Page Source”），避免 SSR 框架注入空
<div class=""> 或无意义 wrapper <li> <code><meta charset="utf-8">必须在前 1024 字节内，否则浏览器可能先按 latin1 解析一部分再重载，导致闪动或乱码——这不是玄学，是规范强制要求
实际项目里最难的不是写代码，而是决定要不要删掉那一层“看起来没什么用但别人写了”的
<div>。删了，DOM 深度降一级，首屏快几十毫秒；留着，它就在那里，不报错，但每次加载都默默拖慢解析、加重重排、干扰爬虫索引。</div> - 别为了“看起来像语义化”而硬套：一个纯装饰性图标容器，用
