cancelAnimationFrame必须传入requestAnimationFrame返回的ID而非函数引用；ID需及时保存、作用域可访问、取消前校验有效性（如Number.isInteger），取消后重置为null，避免重复调用或无效操作。
cancelAnimationFrame 必须传入 requestAnimationFrame 返回的 ID
它不是靠函数引用或名称取消，而是靠 requestAnimationFrame 调用后返回的数字 ID。漏存这个 ID，就完全无法取消——这是最常踩的坑。
常见错误现象：cancelAnimationFrame(myAnimation) 报错或无效，因为 myAnimation 是函数本身，不是 ID；或者 ID 被覆盖、未声明为可访问变量。
- 正确做法：调用
requestAnimationFrame时立刻保存返回值，例如let animationId = requestAnimationFrame(animate) - ID 是一次性有效的，下次调用
requestAnimationFrame会返回新 ID，旧 ID 不再可用 - 在事件处理（如点击暂停）或条件判断中取消时，确保该 ID 变量作用域可访问（避免定义在闭包内却试图从外部取消）
取消前必须检查 ID 是否有效
cancelAnimationFrame 接收 0、null、undefined 或非法数字时不会报错，但也不会起作用——这会让调试变得隐晦：你以为取消了，其实什么都没发生。
使用场景：动画可能尚未启动（ID 还是初始值），或已被取消过一次，又重复调用取消逻辑（比如多次点击“停止”按钮）。
- 建议统一用
if (animationId !== null && animationId !== undefined)或更稳妥地if (Number.isInteger(animationId))判断 - 取消后立即将 ID 重置为
null，避免重复取消或误用已失效 ID - 不要依赖 try/catch 捕获 cancel 的异常——它根本不会抛错
与 requestAnimationFrame 配合实现可控动画循环
原生动画循环不自带暂停/恢复，得靠手动控制 ID 的发起与取消。关键不是“怎么写动画”，而是“什么时候不该继续调用 requestAnimationFrame”。
性能影响：如果忘记取消，即使页面不可见或用户切换标签页，动画帧仍可能在后台排队（尤其在未加 document.hidden 检测时），浪费 CPU 和电量。
- 标准模式是在动画函数末尾按条件决定是否继续：
if (shouldContinue) animationId = requestAnimationFrame(animate) - 暂停时只取消当前帧，不阻止后续手动重启；停止时需取消 + 清空 ID + 重置状态变量
- 配合
visibilitychange事件自动暂停可大幅提升能效，例如监听document.hidden后调用cancelAnimationFrame
浏览器兼容性与 polyfill 注意点
所有现代浏览器都支持 cancelAnimationFrame，但 IE10 及以下仅支持带前缀的 msCancelAnimationFrame，且 IE9 完全不支持。
如果你的项目还需兼容老 IE，不能只靠 feature detection 判断是否存在 cancelAnimationFrame，因为前缀 API 名不同。
- 推荐写法：
const cancel = window.cancelAnimationFrame || window.msCancelAnimationFrame || window.mozCancelAnimationFrame || window.webkitCancelAnimationFrame - 注意：前缀版函数和标准版参数行为一致，但 polyfill 无法修复 IE9 的缺失，只能降级为
setTimeout模拟 - Node.js 环境或测试中无该 API，若用 JSDOM，需确认版本是否启用
requestAnimationFrame支持（默认关闭）
真正容易被忽略的是 ID 的生命周期管理——它不像定时器那样有明确的“已清除”状态，也不像 Promise 那样可链式追踪。一旦丢失，就彻底失去对那一帧的控制权。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
