cancelAnimationFrame 必须传入 requestAnimationFrame 返回的有效帧 ID 才能取消未执行的帧请求，无法中断已进入回调队列的当前帧；动画函数内部须加状态守卫提前 return，避免多余操作和内存泄漏。
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'
