删掉几个节点反而让页面更慢，是因为删除了“高密度低价值”节点后，css选择器匹配路径变长或触发意外分层；例如空div被div div div .content选中时，浏览器需遍历三层嵌套拖慢首屏渲染，ios safari对超5层flex嵌套实测帧率跌落，chrome中单父容器子元素超50个会使样式计算呈非线性增长。
为什么删掉几个反而让页面更慢
不是节点越少越好，而是得看删掉的是不是“高密度低价值”节点。比如一个空的 <div></div> 看似无害，但如果它被 CSS 选中为 div div div .content 的一部分，浏览器就得在每次样式计算时遍历三层嵌套——这种选择器在 Chrome 中会显著拖慢首屏渲染。
- 检查开发者工具的 Layers 面板，确认是否因
transform 或 will-change 导致意外分层，哪怕结构扁平也卡顿
- iOS Safari 对超过 5 层嵌套的
flex 容器有实测帧率跌落点，不是理论值，是真卡
- 单个父容器下子元素建议 ≤ 50 个：超出后，Chrome 的样式计算时间呈非线性增长，尤其当这些子元素还带
style 属性或绑定事件
section 和 div 到底什么时候该换
<section></section> 不是语义装饰品，它只有和 <h2></h2> 及以上标题一起出现才有可访问性价值；单独一个没标题的 <section></section> 和 <div> 在读屏软件里完全等价。
<ul>
<li>必须用 <code><header></header>、<nav></nav>、<main></main>、<footer></footer>：它们自带隐式 ARIA role，不加 role 也能被识别
<section></section> 应表示“与当前内容相关但可独立存在的信息”，比如引用、注释、广告位；滥用会导致逻辑混乱，辅助技术用户反而更难导航
避免 <section><section><section></section></section></section> 嵌套：三层已接近人类认知上限，再深就该拆页或改成交互式折叠
表格渲染万级数据时为什么卡死
<table> 的 layout 算法是 O(n²) 级别，哪怕加了 <code>table-layout: fixed，首行解析仍要遍历所有列宽定义。1000 行 × 20 列的表格，在低端设备上可能触发长达 300ms 的 layout block。
- 万级数据别用
<table> 渲染：改用 <code><div> + CSS Grid 或虚拟滚动（如 <code>react-window）
- 真要用
<table>，必须配 <code><thead> 和 <code><tbody>，否则 JS 查询 <code>document.querySelectorAll('tr') 会遍历整个 DOM 树而非仅 body 区域
-
<caption></caption> 每个表格只能有一个，且必须放在 <table> 最外层——放错位置会导致屏幕阅读器跳过整张表
<h3>动态插入大量节点时怎么不重排</h3>
<p>逐个 <code>appendChild 是性能杀手：100 个子节点触发 100 次重排。浏览器解析 HTML 是单线程流式处理，每多一层嵌套，就多一次 DOM 节点创建 + 样式计算开销。
- 优先用
DocumentFragment 批量挂载：先 append 到 fragment，最后一次性插入 DOM
- 避免在循环里反复查询
document.getElementById 或 querySelector，缓存父容器引用
- 如果节点带内联样式或事件监听，用
data- 属性解耦逻辑，而不是靠深层嵌套 class 名定位
实际项目里最常被忽略的，是“语义足够让辅助技术理解”和“嵌套浅到不拖慢解析”之间的那个临界点——它不在文档里，而在你打开 Layers 面板、测一帧渲染耗时、听一遍读屏朗读顺序之后。
不是节点越少越好，而是得看删掉的是不是“高密度低价值”节点。比如一个空的 <div></div> 看似无害，但如果它被 CSS 选中为 div div div .content 的一部分，浏览器就得在每次样式计算时遍历三层嵌套——这种选择器在 Chrome 中会显著拖慢首屏渲染。
- 检查开发者工具的 Layers 面板，确认是否因
transform或will-change导致意外分层，哪怕结构扁平也卡顿 - iOS Safari 对超过 5 层嵌套的
flex容器有实测帧率跌落点，不是理论值，是真卡 - 单个父容器下子元素建议 ≤ 50 个：超出后，Chrome 的样式计算时间呈非线性增长，尤其当这些子元素还带
style属性或绑定事件
section 和 div 到底什么时候该换
<section></section> 不是语义装饰品，它只有和 <h2></h2> 及以上标题一起出现才有可访问性价值；单独一个没标题的 <section></section> 和 <div> 在读屏软件里完全等价。
<ul>
<li>必须用 <code><header></header>、<nav></nav>、<main></main>、<footer></footer>：它们自带隐式 ARIA role，不加 role 也能被识别
<section></section> 应表示“与当前内容相关但可独立存在的信息”，比如引用、注释、广告位；滥用会导致逻辑混乱，辅助技术用户反而更难导航<section><section><section></section></section></section> 嵌套：三层已接近人类认知上限，再深就该拆页或改成交互式折叠表格渲染万级数据时为什么卡死
<table> 的 layout 算法是 O(n²) 级别，哪怕加了 <code>table-layout: fixed，首行解析仍要遍历所有列宽定义。1000 行 × 20 列的表格，在低端设备上可能触发长达 300ms 的 layout block。
- 万级数据别用
<table> 渲染：改用 <code><div> + CSS Grid 或虚拟滚动（如 <code>react-window） - 真要用
<table>，必须配 <code><thead> 和 <code><tbody>，否则 JS 查询 <code>document.querySelectorAll('tr')会遍历整个 DOM 树而非仅 body 区域 -
<caption></caption>每个表格只能有一个，且必须放在<table> 最外层——放错位置会导致屏幕阅读器跳过整张表 <h3>动态插入大量节点时怎么不重排</h3> <p>逐个 <code>appendChild是性能杀手：100 个子节点触发 100 次重排。浏览器解析 HTML 是单线程流式处理，每多一层嵌套，就多一次 DOM 节点创建 + 样式计算开销。- 优先用
DocumentFragment批量挂载：先 append 到 fragment，最后一次性插入 DOM - 避免在循环里反复查询
document.getElementById或querySelector，缓存父容器引用 - 如果节点带内联样式或事件监听，用
data-属性解耦逻辑，而不是靠深层嵌套 class 名定位
- 优先用
