dom嵌套超4层直接拖慢滚动帧率，因浏览器深度优先遍历导致dom构建变慢且css选择器匹配成本指数上升，需用devtools定位子节点爆炸容器并优化结构。
DOM 嵌套超 4 层直接拖慢滚动帧率
浏览器解析 HTML 是深度优先遍历，每多一层嵌套，不仅 DOM 构建变慢，CSS 选择器匹配成本也指数上升。比如 .a .b .c .d p 这类选择器，浏览器要逐层回溯父节点，实际开销远超线性增长。
- 用 DevTools Elements 面板运行
document.querySelectorAll("*").forEach(el => el.children.length > 5 && console.log(el.tagName, el.children.length))，快速揪出子节点爆炸的容器 - 对返回结果右键 → “Break on” → “Attribute modification”，确认是否被 JS 动态塞内容——这类容器优先改用
<template></template>或延迟挂载 - 能扁平化的结构别硬套 wrapper：比如
<div><div><div><p>文本</p></div></div></div>直接换成<p>文本</p> - 若中间层承载了
aria-live或data-testid，保留但换用display: contents（注意 Safari 15.4+ 才支持）
非首屏内容不能只靠 display: none
display: none 只是视觉隐藏，DOM 已建、CSSOM 已算、内存已占，首次显示时仍需完整重绘，和新挂载开销等同。真正轻量的做法是彻底移除或用 hidden 属性替代。
- 首屏外的大型区块（如文档中 12 个可切换章节）初始状态应设为
hidden，而非display: none—— 它跳过渲染树构建，比 CSS 隐藏更轻量 - 滚动中动态激活时，先移除
hidden，再通过IntersectionObserver或滚动偏移阈值控制显隐时机，避免在scroll回调里反复读offsetTop - 页脚若为“伪页脚”（如含 120 行评论 + 头像 + 折叠按钮），DOM 节点超 800 个，即使
display: none也持续占用资源，必须启用虚拟滚动或滚动距离阈值显隐（例如scrollTop > document.body.scrollHeight - 1500才激活）
scroll 事件监听器一挂就掉帧的真相
移动端每秒可能触发上百次 scroll，Chrome 默认把它标记为“可能调用 preventDefault()”，会等 JS 执行完才滚动，造成肉眼可见延迟。
- 必须加
{ passive: true }：否则控制台报"Unable to preventDefault inside passive event listener"，且滚动明显滞后 - 禁止在回调里读
getBoundingClientRect()或写el.style.top—— 这会触发强制同步布局（forced synchronous layout） - 读位置优先用
el.scrollTop，而不是window.scrollY；真需要响应位置变化，改用requestIdleCallback()或时间戳节流（比如只在停止后 100ms 执行） - 对滚动中要动画的元素，加
transform: translateZ(0)或临时设will-change: transform（滚动开始前加，结束后 100ms 移除），避免图层爆炸
语义标签替换不是搜索替换就能过关
把 class="main" 换成 <main></main> 不是简单查找替换，HTML 语义标签自带契约约束，Lighthouse 会立刻报错。
-
<main></main>页面里只能有一个，哪怕一个在<dialog></dialog>里也会被扫到 - 面包屑或分页塞进
<nav></nav>，屏幕阅读器会误判为主导航；页脚链接组应放在<footer></footer>内<ul></ul>，而非<nav></nav>套<div><li>不加标题的 <code><section></section>等价于<div>；所有语义标签必须闭合，<code><header></header>不能是<main></main>的子元素却漏掉，否则 DOM 树会被浏览器自动修正，导致 SSR/CSR 渲染不一致滚动性能问题从来不在“怎么动”，而在“动之前 DOM 是否干净、语义是否可信、监听是否克制”。最常被忽略的是：页脚看似无关紧要，一旦它内部有未设宽高的图片、浮动子元素或参与
scroll计算，就会成为全页重排的导火索。
