使用cancelAnimationFrame停止动画帧循环

`cancelAnimationFrame` 并非“立即刹车键”，它只能取消尚未执行的未来帧请求，而无法阻止已进入回调队列的当前帧运行；真正可靠的动画控制依赖双重保障：一是严格配对使用——每次 `requestAnimationFrame` 返回的帧 ID 必须保存并在适当时机传入 `cancelAnimationFrame`，二是动画函数内部必须设置状态守卫（如 `if (!shouldAnimate) return`），主动拦截多余执行，避免内存泄漏、无效渲染和意外副作用——尤其在组件卸载、元素移除等关键节点，遗漏清理将导致后台空转、CPU 白耗和持续掉帧，而这些隐患往往静默发生、难以调试。

cancelAnimationFrame 必须配对 requestAnimationFrame 使用

单独调用 cancelAnimationFrame 没有效果，它只能取消之前由 requestAnimationFrame 返回的帧请求 ID。如果你没保存这个 ID，就根本没法取消。

常见错误是直接写 cancelAnimationFrame() 而不传参，或者传了错的变量（比如传了函数引用、null 或未定义值），这时控制台通常不会报错，但动画照常运行。

• 每次调用 requestAnimationFrame 都要存下返回值：const frameId = requestAnimationFrame(animate)
• 取消时必须传入这个 frameId：cancelAnimationFrame(frameId)
• 取消后建议把 frameId 设为 null 或 0，避免重复取消或误用

动画逻辑里忘记清理会导致内存泄漏和持续掉帧

如果动画函数内部递归调用 requestAnimationFrame（比如在末尾又调一次自己），但外部条件变化后没及时取消，那即使 DOM 元素已移除、组件已卸载，帧循环仍在后台执行——CPU 白跑，还可能触发渲染管线重排。

典型场景：React 组件中启用了动画，但 useEffect 清理函数没调 cancelAnimationFrame；或 Vue 的 beforeUnmount 里漏掉了这步。

• 务必在组件销毁、元素隐藏、状态退出动画模式时主动取消
• 不要依赖用户“离开页面”来终止——浏览器未必立即释放帧请求
• 可加一层守卫判断：if (isAnimating) frameId = requestAnimationFrame(animate)

cancelAnimationFrame 无法取消已进入回调队列的帧

cancelAnimationFrame 只影响尚未执行的帧请求。如果某次 requestAnimationFrame 已被调度进下一帧的回调队列（比如刚调完还没到绘制时机），此时调用 cancelAnimationFrame 也拦不住它执行——这一帧仍会跑。

这意味着：不能靠它做“紧急刹车”，而应靠逻辑控制让动画函数提前 return。例如：

function animate() {
  if (!shouldAnimate) return; // 关键守卫
  // ... 动画逻辑
  requestAnimationFrame(animate);
}

• cancelAnimationFrame 是取消“未来帧”的调度，不是中断“当前帧”的执行
• 动画函数体内必须检查状态并提前退出，否则最后一帧仍可能造成多余操作（如 setStyle、触发 reflow）
• 尤其注意异步动画（如配合 setTimeout 模拟的）不适用此 API，它只管 RAF 队列

跨浏览器兼容性基本无坑，但要注意 ID 类型

所有现代浏览器（包括 Safari 6.1+、Chrome 24+、Firefox 23+、Edge 12+）都支持 cancelAnimationFrame，且 ID 是数字类型。IE10/11 需要用带前缀的 msCancelAnimationFrame，但目前已可忽略。

• 别把帧 ID 当对象或字符串处理；它是整数，可直接比较或存储为 number
• 某些 polyfill 会把 ID 包装成对象，此时原生 cancelAnimationFrame 可能失效——确认你没混用 polyfill
• Node.js 环境没有该 API，服务端渲染时需 guard：typeof requestAnimationFrame !== 'undefined'

本篇关于《使用cancelAnimationFrame停止动画帧循环》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！