读写混用会立刻卡住页面，因为JS中读取offsetHeight等布局信息时，浏览器必须同步执行重排才能返回准确值，强制打断渲染流水线；应采用读写分离策略：先批量读取、再批量写入，并优先使用transform/opacity等不触发重排的属性。
为什么读写混用会立刻卡住页面
浏览器在 JS 执行中一旦读取 offsetHeight、getBoundingClientRect()、clientWidth 等布局信息，就必须立刻 flush 排队中的样式修改，同步执行一次重排，才能返回准确值。这不是性能“差一点”，而是每次调用都强制打断渲染流水线。
常见错误现象：
- for 循环里每轮都
el.style.left = i + 'px'然后立刻el.offsetTop - 先改
el.className = 'active'，马上又读el.offsetHeight - 用
document.getElementsByTagName('div')这种实时集合，在循环中反复访问其.length或索引项
读写分离的三步实操法
核心不是“别读”，而是“读完再写”“写完再读”。把所有布局读取集中到前半段，所有 DOM 修改集中到后半段，让浏览器有机会批量处理。
- 先批量读：把所有需要的
offsetTop、getComputedStyle(el).color、el.getBoundingClientRect()结果存进数组或对象，不穿插任何写操作 - 再批量写：统一用
el.classList.add()、el.setAttribute('class', ...)或一次性设置el.style.cssText = 'transform: translateX(10px); opacity: 0.8;' - 若需动画或高频更新，把写操作包进
requestAnimationFrame：它不能避免读取触发的重排，但能确保所有写入合并到同一帧，减少重排次数
哪些读操作必须警惕（哪怕只调一次）
以下 API 只要出现，就等于向浏览器发了“立刻重排”的指令。它们不是“可能触发”，而是“必然触发”，且无法被节流或防抖绕过：
-
offsetTop/offsetLeft/offsetWidth/offsetHeight -
clientTop/clientLeft/clientWidth/clientHeight -
scrollWidth/scrollHeight/scrollTop/scrollLeft getBoundingClientRect()-
getComputedStyle()（只要访问返回对象里的 width/height/top/left 等 layout 属性）
注意：getComputedStyle(el).color 不触发重排，但 getComputedStyle(el).width 会 —— 区别在于是否依赖当前布局计算结果。
替代方案：用 transform 和 opacity 规避读写冲突
如果目标只是位移、缩放、透明度变化，完全不需要读取任何布局信息，也无需修改影响盒模型的属性：
- 用
el.style.transform = 'translateY(20px) scale(0.95)'替代el.style.top = '20px'; el.style.width = '180px' - 用
el.style.opacity = '0.7'替代el.style.visibility = 'hidden'（后者虽不重排，但会触发重绘+布局影响） - 对需要频繁动画的元素，提前加
style="will-change: transform;"或用contain: paint隔离，避免重排扩散
真正容易被忽略的是：即使你没手动读取 offset，某些 UI 库内部的测量逻辑（比如弹窗自动定位、虚拟滚动计算高度）也会悄悄触发 —— 查看 DevTools 的 Rendering 面板勾选“Layout Shift Regions”，能直观看到哪些区域被强制重排了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
