碰撞检测必须加节流，因其每帧执行会引发重绘卡顿、CPU飙升、FPS骤降；推荐时间戳节流或结合requestAnimationFrame的标志位方案，配合缓冲距离、按需启用、分层检测与取消机制优化体验。
在页面元素碰撞检测中直接高频执行判断逻辑，容易引发重绘卡顿、CPU飙升，尤其在 requestAnimationFrame 或 scroll / mousemove 事件中持续调用时。节流不是去掉检测，而是让检测“有节奏地发生”，既保响应又不压垮浏览器。
为什么碰撞检测必须加节流
矩形碰撞检测（如用 getBoundingClientRect() 对比坐标）看似轻量，但若每帧都执行，叠加 DOM 查询、浮点计算、频繁重排，实际开销远超预期。实测表明：未节流的连续碰撞检测在低端设备上可使 FPS 掉至 20 以下；而加入合理节流后，稳定维持在 55–60 FPS，视觉体验明显更顺滑。
推荐用时间戳节流控制检测频率
碰撞检测属于“需要及时反馈”的场景——比如拖拽元素靠近障碍物时，用户期望立刻看到偏移或高亮。时间戳方案首次触发即执行，且能严格保证“每 N 毫秒最多检测一次”，逻辑清晰、无定时器堆积风险，最适合此类需求。
- 设定合理间隔：一般取 16ms（≈60fps） 或 32ms（≈30fps），匹配屏幕刷新节奏，避免丢帧
- 保留
this和事件参数：检测函数常需访问被拖拽元素或鼠标位置，节流包装后务必用fn.apply(this, arguments)透传上下文 - 避免在节流函数内做 heavy DOM 操作：检测只返回布尔值或碰撞方向，具体修正动作（如移动、样式更新）放到主渲染流程中统一处理
结合 requestAnimationFrame 的增强写法
纯 setTimeout 或时间戳节流虽可靠，但与浏览器渲染周期不同步。更优做法是把节流后的碰撞检测挂到 requestAnimationFrame 队列中，确保它总在下一帧绘制前执行：
立即学习“Java免费学习笔记（深入）”；
- 用一个标志位（如
pending = false）控制是否已提交 rAF 任务 - 每次需要检测时，若
!pending，则调用requestAnimationFrame(checkCollision)并置pending = true -
checkCollision执行完后置pending = false，开放下一次提交入口 - 这样既获得 rAF 的渲染协同优势，又通过标志位实现了等效节流，无需手动管理毫秒级时间差
实际应用中的关键细节
节流只是第一步，真正影响体验的是如何配合使用：
-
缓冲距离提前触发：不要等两个元素完全重叠才检测，用
rect1.left 这类带 5–10px 缓冲的条件，让避障反应更自然 -
按需启用检测：仅当元素处于运动状态（如
isDragging === true）时才开启节流检测，静止时完全关闭 - 分层检测优先级：先粗筛（如用元素中心点距离快速排除远距离对象），再细判（精确矩形交集），节流应作用于细判环节
- 取消机制不可少：组件卸载或拖拽结束时，清空 rAF ID 或重置节流状态，防止内存泄漏或误触发
