dom节点超1500时低端设备易卡顿，因gc频繁、解析与样式计算开销剧增；嵌套超5层致首屏延迟20–50ms；冗余div应删，但须保留承担布局、语义或交互职责者。
DOM节点数超1500时页面开始卡顿
浏览器解析HTML是深度优先遍历，每个div节点至少占1–2 KB内存，嵌套每深一层，样式匹配、事件监听、重排（reflow）开销就非线性增长。实测发现：DOM节点数超过1500后，低端设备上GC频繁触发，滚动卡顿肉眼可见；嵌套超过5层（如<div><div><div><div><div>）会让首屏渲染延迟20–50ms。
<p>不是所有<code>div都该删——关键是看它有没有承担以下任一职责：
- 带
class、id、style、onclick等属性 - 参与Flex/Grid布局的容器角色（如设了
display: flex） - 承载语义（比如包裹
article内容但自身有role="region"）
纯“撑结构”用的div，比如只为加margin或包住一个flex容器，99%可直接移除。
用Chrome DevTools快速定位冗余嵌套
打开Elements面板，手动展开DOM树，重点扫视连续出现、无任何属性的div块。更高效的方式是控制台执行：
document.querySelectorAll('div:not([class]):not([id]):not([style]):not([onclick])')
这条语句能批量选中“裸div”，但注意：仅用于调试，切勿上线运行。结果出来后，逐个右键→“Break on > subtree modifications”，再刷新页面，观察哪些节点被JS动态插入——这些可能是框架生成的冗余根节点，需在组件层改用Fragment或render props绕过。
常见陷阱：
- CMS导出的HTML常带四层固定结构：
<div class="wrapper"><div class="container"><div class="row"><div class="col">…</div></div></div></div>，通常只保留最内层div即可 - Vue/React开发中，
<div id="app">若没绑定事件、没设ref、没加class，可直接删掉，让根组件挂载到<code>或语义化标签上语义化标签不是为了SEO，而是省计算资源
<header></header>、<main></main>、<section></section>这些标签本身不增加内存，反而减少开销：浏览器对它们有原生优化，CSSOM复用样式规则更高效，ARIA解析比div role="main"少一次属性遍历。替换时注意实际效果差异：
-
<main></main>自带隐式流式行为和默认margin，比<div class="main-content">少1–2行reset CSS <li> <code><picture></picture>+<source></source>比JS动态换图节省主线程执行时间，且支持原生preload - 用
display: grid直接设在<main></main>上实现三栏布局，比套三层div（row/col/col）少2个节点、省3–4KB内存 - 老写法（4层）：
<div class="row"> <div class="col"><img></div> <div class="col"><p>text</p></div> </div> - 新写法（1层）：
<section style="display: flex; gap: 1rem;"><img><p>text</p></section> - Grid适合二维布局（如仪表盘、卡片网格），Flex适合一维（导航、表单）；混用（Grid里套Flex微调）往往暴露逻辑拆分不清
-
display: contents虽能让父元素不参与盒模型，但IE不支持，且会剥离可访问性树节点，慎用 - 避免在Grid容器里再设
display: flex——先确认是否真需要“网格内再分组”，还是该拆成两个独立section
别为了语义硬套标签——
<div class="card">比<code><article class="card"></article>更合理，如果它只是UI卡片而非独立文章内容。Flex/Grid布局能一步砍掉2–3层包裹
传统浮动或inline-block布局依赖父容器清除浮动、子项浮动，必然引入额外
div；而Flex/Grid把布局逻辑收束到单层容器上，子元素无需包裹。典型改造示例：
注意事项：
真正难的是判断哪一层该删：不是看代码多不多，而是看浏览器是否为它创建了不必要的布局上下文。一个没样式、没交互、没语义的
div，就是性能负债。 -
