dom深度超6层时，应优先扁平化无语义、无样式、纯包裹的冗余标签，如三连div嵌套、语义标签被冗余容器包围、为样式硬塞的多层span；删除标准是向上无样式或事件绑定的空节点。
DOM深度超6层时，哪些标签必须优先扁平化
DOM树深度≥7就该动手，但不是所有嵌套都一样危险。真正拖慢渲染的是那些既无语义、又没样式、纯靠
<div class="wrapper"><div class="content"><div class="inner">——这种三连嵌套是重排放大器，JS改个<code>padding会波及整棵子树-
<main></main>被套在<section><div class="page">里——语义标签被冗余父容器包围，浏览器无法跳过其子树解析 <li> <code><button><span><span><span>点击</span></span></span></button>——为加hover效果硬塞三层span，类名全靠CSS选择器定位，样式计算链翻倍 -
<main></main>和<aside></aside>设display: none时，浏览器直接跳过子树构建；普通<div>即使隐藏，仍要走完解析+样式计算全流程 <li> <code><details><summary></summary></details>替代手写展开收起的5层结构，能省掉JS控制逻辑和对应DOM节点- 把首屏标题、主按钮直接放在
下一级，最多嵌套2层——这是Chrome实测getComputedStyle()卡顿从80ms降到12ms的关键阈值别为了语义强行改结构：如果一个
<article></article>里只有<p></p>和<img>，那它和<section></section>性能差异几乎为零；但若它被<div class="container">包着，反而多一层遍历。 <h3>表格类长文档，不改分页也能提速的关键动作</h3> <p>6万行表格白屏1分钟，问题不在数据量，而在浏览器必须等整行<code><td>收齐才建DOM。哪怕你只想要前10行，第11行缺个闭合标签，整个表格就卡死。 <ul><li>确保<code><tr>和<code><td>严格成对闭合——Vue/React模板里用v-for生成时，容易漏掉<code>导致解析中断- 禁用
colspan/rowspan：跨行合并会强制浏览器回溯整表结构，实测开启后layout耗时涨3倍- 真要流式渲染，别用
innerHTML +=拼接HTML字符串，改用DocumentFragment批量append，每批≤200行更激进但有效的做法：把
<table>换成<code><div role="table"> + <code>display: grid，配合grid-template-columns模拟列宽，DOM节点数下降60%，且支持原生滚动锚点。为什么删了三层嵌套，页面还是卡
因为性能瓶颈常不在DOM本身，而在CSS选择器的回溯路径。删掉
<div class="nav">，但CSS还写着<code>.page .header .nav .item a，浏览器照样从每个a往上验证4层祖先是否存在。- BEM类名如
nav__item--active本质是把结构“编译”进类名，让匹配降为单次查找 - SCSS里
&:hover嵌套5层，编译后仍是.menu .menu__item:hover这种高成本选择器 - 把修饰符提级：
menu__item--hover比依赖.menu:hover .menu__item快得多
最容易被忽略的一点：你花一小时删DOM嵌套，不如花五分钟检查
devtools → Styles面板 → 选中元素 → 看匹配的选择器链长度。链长＞4，就是下一个该砍的地方。 - 把首屏标题、主按钮直接放在
优先删掉的不是“最深那一层”，而是“向上找不到任何样式或事件绑定”的空节点。用DevTools右键→Show DOM properties查node.depth，再顺手跑document.querySelectorAll('div').length，超300个纯
语义化标签怎么用才真提速，而不是只图个好看
不是写了<header></header>就自动变快，关键看它是否参与了浏览器的内部优化路径。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
