响应式布局本身不触发重排，真正拖慢页面的是html中尺寸未知的写法及js错误读写布局信息：img/iframe缺宽高属性、inline-block+vertical-align动态计算、js同步读取布局、嵌套过深结构均会引发重排。
响应式布局本身不触发重排，真正拖慢页面的是 HTML 结构中那些“浏览器无法提前知道尺寸”的写法，以及 JS 中错误读写布局信息的行为。
img 和 iframe 缺 width/height 属性会立即触发重排
浏览器解析到 <img> 但没看到 width 和 height 属性时，初始占位是 0×0 或行内默认尺寸；等图片加载完成，才强制重排——下方所有内容被顶下去，CLS 直接超标。
-
<img src="a.jpg" style="max-width:90%" style="max-width:90%">是最稳妥的写法，兼容所有浏览器，包括旧版 Safari - 仅靠
aspect-ratio: 16/9或max-width: 100%不够，某些首帧仍 fallback 到无占位状态 -
<iframe></iframe>同理：必须用 CSS 显式设宽高，或组合width: 100%+aspect-ratio，否则加载瞬间撑开父容器 - JS 动态插入图片时，
new Image()append 前必须先设width/height，CSS 补救无效
display: inline-block + vertical-align 是隐藏重排源
当父容器设 display: inline-block，子元素用 vertical-align: middle，浏览器必须逐个计算兄弟元素高度才能对齐——滚动、resize 或文本变化都可能触发局部重排，抖动不易复现但高频发生。
- 常见现象：滚动时文字块轻微跳动、图标和文字基线忽高忽低
- 替代方案优先用
display: flex+align-items: center，或display: grid - 若必须保留 inline-block，把
vertical-align换成固定值如vertical-align: top，避免依赖动态计算 - 不要在媒体查询中动态切换
vertical-align值，改用 class 控制整套对齐逻辑
JS 中读取 offsetWidth/getBoundingClientRect() 是动画卡顿主因
在 requestAnimationFrame 回调里调用 getBoundingClientRect() 或 offsetHeight，等于命令浏览器立刻 flush 渲染队列、强制同步重排——每帧一次，120Hz 设备上直接掉帧。
- 读取布局信息前，确保 DOM 已稳定（比如 resize 后等一帧再读）
- 循环中反复查
element.offsetWidth？提前缓存到变量里 - resize 事件里禁用
getBoundingClientRect()，改用requestAnimationFrame节流后读 - 响应式断点切换时，别用 JS 计算并设
style.width，改用 CSS 原生能力：clamp()、minmax()、aspect-ratio
结构嵌套过深 + 无意义包裹层放大高刷屏瓶颈
120Hz 设备要求每帧 ≤8.3ms 完成样式计算→布局→绘制；一个 <div><div><div><p>文字</p></div></div></div> 这类三层包裹，会让浏览器多走几次 layout 流程，单次重排耗时轻松突破阈值。
-
<main></main>和首屏内容必须紧贴开头，避免被顶部脚本阻塞解析 - 删掉所有语义无关的
<div> 包裹，用 <code><p></p>、<section></section>等原生标签直出 - 禁用
<table> 做页面骨架——表格需整行解析完才开始渲染，比 <code>flex多一次重排且无法增量渲染 - 对动画区域加
contain: layout style paint，隔离影响范围（注意 Safari 15.4+ 才支持）
最难的不是写出不重排的代码，而是让结构设计、CSS 媒体查询和 JS 交互三者彼此解耦——一旦某处用 JS 强行补尺寸，就说明 HTML 结构本身已经埋了雷。
