iPad上requestAnimationFrame卡顿主因是iOS Safari节流，需验证performance.now()间隔；canvas须按DPR重设宽高并缩放；CSS动画需确保元素已布局且避免opacity+visibility隐藏；WebGL需检查帧缓冲、生成mipmap并适配芯片。
iPad 上 requestAnimationFrame 不触发或卡顿
HTML5 动画在 iPad 上无响应，大概率不是代码写错了，而是 requestAnimationFrame 被系统节流或挂起。iOS Safari 对后台标签页、滚动中、低功耗模式下的 RAF 有激进优化，动画循环可能被降频到 10fps 甚至暂停。
- 用
performance.now()打点验证：连续两次requestAnimationFrame回调间隔超过 16ms（即非 60fps），基本可确认被节流 - 避免在
scroll或touchmove中直接启动动画循环；改用passive: false+preventDefault()配合will-change: transform提前声明 - 若动画依赖用户交互（如拖拽），务必在第一次
touchstart或pointerdown后才首次调用requestAnimationFrame—— iOS 会拒绝静默启动的动画上下文
canvas 动画在 iPad 上黑屏或只闪一帧
常见于未显式设置 canvas 的 width 和 height 属性（仅靠 CSS 缩放），或未适配 Retina 屏。iPad 的高 DPR 会让 canvas 缓冲区严重失真，导致清空失效、绘图偏移、甚至渲染管线拒绝提交。
- 必须用 JS 设置：
const dpr = window.devicePixelRatio || 1; canvas.width = canvas.clientWidth * dpr; canvas.height = canvas.clientHeight * dpr; ctx.scale(dpr, dpr);
- 避免在
resize事件中频繁重设 canvas 尺寸 —— 每次都会清空缓冲区并触发重绘，建议加防抖（setTimeout延迟 100ms） - 若使用
createImageBitmap加载帧序列，需确认图片已完全解码：img.decode()Promise resolve 后再绘制，否则 iPad 上易出现空白帧
CSS @keyframes 动画在 iPad Safari 中不播放
iPad Safari 对 CSS 动画的触发条件比桌面 Chrome 更苛刻：元素必须“进入文档流且尺寸不为 0”，且部分属性（如 transform: scale(0)）会导致动画被跳过。
- 确保动画元素已插入 DOM 且完成 layout —— 可在
setTimeout(() => { /* 添加 animation 类 */ }, 0)中触发，绕过 Safari 的同步样式计算阻塞 - 禁用
animation-play-state: paused的初始状态；改用 class 控制启停，避免首次渲染时被 Safari 当作无效动画丢弃 - 慎用
opacity: 0+visibility: hidden隐藏动画元素 —— iPad Safari 可能直接跳过整个动画生命周期；改用position: absolute; left: -9999px等不影响渲染树判断的方式
WebGL 动画导入后卡死或报 INVALID_OPERATION
iPad GPU 驱动对 WebGL 状态管理极敏感。常见于纹理未绑定、帧缓冲未完整、或 shader 中使用了未启用的扩展（如 OES_texture_float 在旧 iPad 上不可用）。
立即学习“前端免费学习笔记（深入）”；
- 每次
gl.drawArrays前检查gl.checkFramebufferStatus(gl.FRAMEBUFFER) === gl.FRAMEBUFFER_COMPLETE - 纹理上传后必须调用
gl.generateMipmap(gl.TEXTURE_2D)（即使不用 mipmap），否则某些 iPad 型号会拒绝后续绘制 - 用
gl.getExtension('WEBGL_debug_renderer_info')获取设备型号字符串，对 A12 及以下芯片降级使用gl.LINEAR而非gl.LINEAR_MIPMAP_LINEAR
实际项目里最常被忽略的是：iPad 上动画逻辑和资源加载的时序耦合太紧。比如在 DOMContentLoaded 就启动 canvas 动画，但此时图片、字体、WebGL 着色器可能还没就绪 —— 这种“假无响应”比兼容性问题更难排查。
