精简 html 层级可降低屏幕阅读器在低端设备上的解析延迟和焦点卡顿，dom 节点超 800 个时响应可能从 120ms 延至 600ms+；建议首屏控制在 800 以内，内存 ≤2gb 设备压至 500 以内，优先替换冗余 div 为语义标签并验证焦点流。
精简 HTML 层级不是为了“看起来更干净”，而是直接降低屏幕阅读器（VoiceOver、TalkBack、NVDA）在低端 Android 设备或旧版 iOS 上的解析延迟和焦点跳转卡顿。DOM 节点超 800 个时，语音导航响应可能从 120ms 拉长到 600ms+，用户会明显感知“卡顿”或“跳过内容”。
怎么判断 DOM 层级是否过深
Chrome DevTools 的 Elements 面板里右键任意节点 → Reveal in Elements Panel，看左下角显示的 “Nodes: X” 数值。真实项目中，首屏 DOM 节点数超过 800 就该干预；若设备内存 ≤2GB（如三星 Galaxy A12、iPhone SE 第一代），建议压到 500 以内。
- 不要只看
div数量——嵌套的<div><div><div><div> 是最危险的，每多一层，辅助技术遍历时间非线性增长 <li>CMS 或 SSR 框架（如 Next.js）常自动生成 wrapper div，比如 <code><div class="container"><div class="row"><div class="col-12">...</div></div></div>，这类结构必须合并或用语义标签替代 - 检查
aria-hidden="true"区域是否仍被渲染进 DOM —— 它不参与语音播报，但仍在占用解析资源 -
<header></header>和<nav></nav>天然支持焦点快捷键（如 VoiceOver 的 H 键跳标题、M 键跳主内容），无需额外 JS 绑定 - 避免把
<main></main>套在<section></section>或<div class="wrapper"> 里——<code><main></main>必须是顶层元素，否则屏幕阅读器会忽略它或误判为子区域 - 表格不用
div模拟：用<table> + <code><th scope="col">，TalkBack 在竖屏下才能正确读出行列关系；否则用户听到的是“cell, cell, cell…”而不知哪列是姓名、哪列是电话 <h3>哪些“看似合理”的嵌套实际伤害可访问性</h3> <p>低配设备上，辅助技术对 DOM 树的深度遍历比宽度更敏感。以下写法会让 VoiceOver 多花 200ms+ 重建导航树：</p> <ul> <li> <code><div><div><div><button>提交</button></div></div></div>—— 把按钮包了三层无意义容器，应直接用<button></button>或最多一层语义 wrapper（如<section></section>） -
<nav><ul> <li><a>首页</a></li> <li><a>关于</a></li> </ul></nav>是 OK 的，但加一层<div class="nav-inner"> 就多余 <li>React/Vue 中滥用 <code>Fragment或空标签（）包裹多个元素时，若编译后仍生成div，就抵消了 Fragment 的本意；确认构建产物是否真没插入 DOM 节点 - 动态插入内容（如评论区）用
innerHTML拼接时，极易带入冗余div；改用document.createElement+appendChild可控粒度
用语义标签替代 div 堆叠能省多少节点
一个典型的 <div class="header"> + <code><div class="nav"> + <code><div class="main"> + <code><div class="footer"> 结构，共 4 个 div；换成 <code><header></header> + <nav></nav> + <main></main> + <footer></footer> 后，不仅语义正确，还能减少至少 2–3 层 wrapper（尤其当 CSS 使用 display: contents 时）。
真正难的不是删代码，而是识别哪些 wrapper 是业务逻辑必需、哪些只是历史惯性。每次删掉一个无功能 div，都要用 VoiceOver 真机测一遍焦点流是否断裂——有时候少一个节点，反而让“跳到下一个标题”失效，因为大纲层级断了。
