“读写分离”是浏览器渲染优化原则：先集中读取布局信息，再批量修改样式，避免强制回流。每帧混用读写会多次触发回流，耗尽16.6ms；应缓存几何数据，用transform+will-change更新，并及时清理离屏元素。
在 60FPS 游戏循环中，“读写分离”不是指数据库层面的主从架构，而是针对浏览器渲染机制提出的一种 DOM 操作组织原则：把所有“读取布局信息”的操作集中执行（读阶段），再把所有“修改样式或结构”的操作批量执行（写阶段），从而避免触发多次强制回流。
为什么读写混用会拖垮帧率
每次读取 offsetTop、getBoundingClientRect()、clientWidth 等属性时，浏览器必须立刻 flush 队列、执行一次完整回流，以返回准确值。如果在动画循环中边读边写——比如每帧先算位置、再改 left、再算碰撞、再改 transform——就等于每帧强制触发多次回流，16.6ms 很快耗尽。
游戏循环中的读写分离实践
以 requestAnimationFrame 驱动的主循环为例，把一帧拆成明确的两个阶段：
-
读阶段（Read Phase）：仅调用一次
getBoundingClientRect()或缓存所有动态元素的offsetLeft/offsetTop，把所需几何数据全部读出并暂存到 JS 对象中 -
写阶段（Write Phase）：基于已读数据完成全部计算（如位移、碰撞判定、状态更新），然后统一用
transform: translateX(x) translateY(y)批量更新所有元素样式，不读、不查、不判断
配合硬件加速与 DOM 管理进一步降损
仅分离读写还不够，需配套以下做法才能稳住 60FPS：
- 所有移动元素使用
transform+will-change: transform，避免触发布局（layout）和绘制（paint）全通路 - 离开屏幕的元素立即
removeChild并清空数组引用，不靠 display:none 或 visibility:hidden 占着内存和渲染管线 - 不使用
left/top或width/height动态修改，这些属性会直接引发回流 - 若需临时测量，提前在上一帧末尾或初始化阶段完成，本帧只用缓存值
一个轻量但关键的优化示例
错误写法（每帧 3 次强制回流）：
ball.style.left = ball.offsetLeft + 2 + 'px';if (ball.offsetLeft > 500) reset();
enemy.style.top = enemy.offsetTop + 1 + 'px';
正确写法（0 次强制回流）：
const ballRect = ball.getBoundingClientRect();const enemyRect = enemy.getBoundingClientRect();
// 计算逻辑…
ball.style.transform = `translateX(${newX}px)`;
enemy.style.transform = `translateY(${newY}px)`;
