浏览器不存在“读写分离”策略优化 reflow——reflow 是布局树重算，由 dom/cssom 变更触发，而读写分离属数据库概念；offsettop 等读操作强制 reflow 是因需同步获取准确布局值；有效减少 reflow 的方式是批量写样式+异步读布局，如用 classname 切换、requestanimationframe 延迟读取，以及优先使用 transform/opacity 避开布局计算。
浏览器里没有“读写分离”策略能彻底优化 Reflow 耗时——这个说法本身混淆了概念。Reflow（重排）是渲染管线中对布局树的重新计算，它由 DOM/CSSOM 变更触发，而“读写分离”是数据库或并发编程里的模式，浏览器渲染引擎不支持、也不需要你手动实现这种抽象层。
为什么 offsetTop、getComputedStyle 这类读操作会强制触发 Reflow
当 JavaScript 读取某些布局相关属性（如 offsetHeight、clientWidth、getComputedStyle(el).left）时，如果此前有未应用的样式变更（比如刚改了 el.style.width），浏览器必须立即同步执行 Layout（即 Reflow）来给出准确值。这不是“优化没做好”，而是规范要求的确定性行为。
- 连续读-写-读：每次读都可能拉起一次 Reflow，例如循环中交替调用
el.offsetWidth和el.style.left = ... - 即使 DOM 没变，只要样式树有 pending 更新，读取布局信息就会 flush 队列
-
getBoundingClientRect()同样属于强同步读，但比getComputedStyle开销略低（只算几何，不查完整样式）
真正有效的 Reflow 减少手段：批量写 + 异步读
核心不是“分离”，而是避免在单次 JS 执行帧中反复进出 layout 管道。关键在于把所有样式/结构变更攒在一起，再统一读取结果（如有必要）。
- 把多个
el.style.xxx修改合并到一次操作，而不是逐个赋值 - 用
className或classList切换预设 CSS 规则，比内联样式更可控 - 需要读取布局时，放在
requestAnimationFrame回调末尾（确保样式已更新但尚未绘制），或用setTimeout(..., 0)推迟到下一宏任务（让浏览器有机会先完成 layout） - 对动画场景，优先用
transform和opacity，它们走合成线程，完全 bypass Reflow 和 Repaint
容易被忽略的隐式 Reflow 来源
很多 Reflow 并非来自显式 DOM 操作，而是 CSS 规则副作用或测量逻辑本身引入的。
- 使用
table布局时，任意单元格内容变化都可能触发整表重排 - CSS 中
width: auto+float+white-space: nowrap组合在内容动态插入时极易连锁重排 - 在
scroll或resize事件里直接读取el.scrollHeight，且未做节流 —— 滚动过程中每像素都可能触发一次 Reflow - 通过
document.createElement创建元素后立刻 append 并读取尺寸，不如先el.style.display = 'none'，测完再显示
Reflow 不可避免，但高频、意外、跨帧累积的 Reflow 可以消除。重点从来不是模拟某种“读写分离”架构，而是理解浏览器何时必须同步计算布局，并主动让 JS 与渲染管线节奏对齐。
