应使用 requestAnimationFrame 实现动画，它与屏幕刷新率同步、后台自动暂停，配合 performance.now() 计算真实时间差实现精准位移；CSS 动画优先用 transform: translate() 替代 left/top，避免重排重绘，提升渲染性能。
用 requestAnimationFrame 移动小方块才不卡
直接用 setTimeout 或 setInterval 控制移动，大概率掉帧、拖影、手感发飘。浏览器不知道你在做动画，没法优化调度，尤其在低端安卓机上明显卡顿。requestAnimationFrame 是唯一该用的时机控制器——它和屏幕刷新率同步，且页面切到后台时自动暂停。
实操建议：
- 把位移逻辑写在
requestAnimationFrame回调里，不要套在setInterval里 - 用时间戳（
performance.now()）算真实经过毫秒数，别依赖“每 16ms 走一步”的假定 - 位移量 = 速度 × 经过时间（单位统一为 px/ms），避免累积误差
let lastTime = 0;
function animate(currentTime) {
if (!lastTime) lastTime = currentTime;
const delta = (currentTime - lastTime) / 1000; // 秒
x += speed * delta;
element.style.left = x + 'px';
lastTime = currentTime;
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);CSS transform: translate() 比 left/top 快得多
改 left 或 top 会触发浏览器 Layout → Paint → Composite 全流程；而 transform: translate() 只走 Composite，GPU 直接合成，功耗低、帧率稳。iOS Safari 和 Android Chrome 都认这个优化路径。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 小方块移动时文字模糊、边缘锯齿——没开启硬件加速，加
will-change: transform或transform: translateZ(0) - 安卓微信内嵌浏览器中动画突然变慢——检查是否用了
position: absolute+left，换成transform立刻改善 - 快速来回移动后位置偏移——
left值被四舍五入成整数像素，translate支持 sub-pixel 渲染
触摸操作要同时处理 touchstart/touchmove 和 pointerdown/pointermove
只监听 touch 事件，在 Windows 触屏笔或某些安卓平板上会失效；只监听 pointer，老版 iOS Safari（pointer（更标准、支持鼠标/触控/笔统一处理）。
实操建议：
- 先绑定
pointerdown，如果浏览器不支持再 fallback 到touchstart -
touchmove默认会触发页面滚动，记得加event.preventDefault()（但仅限你真正接管了移动逻辑时） - 获取坐标统一用
event.clientX/clientY，别混用touches[0].clientX和event.clientX
移动端需禁用双击缩放和长按菜单
小方块一碰就放大、一按就弹出“复制”菜单，交互完全失控。这不是代码问题，是 viewport 和事件默认行为没关干净。
必须做的两件事：
- 在
里加：<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> - 给小方块容器加 CSS：
-webkit-user-select: none; -webkit-tap-highlight-color: transparent; - 监听
contextmenu并preventDefault，防止长按唤起原生菜单
漏掉任意一项，用户在 iPhone 上点两下，整个页面就 zoom 了——这问题不报错，但直接毁掉体验。
真正在意手感的人，会反复测三台设备：iPhone、小米安卓、iPad。同一段位移逻辑，在它们的 touch 响应延迟、requestAnimationFrame 调度精度、transform 合成效率上全都不一样。没有“一次写完到处跑”的移动动画，只有逐个对齐的妥协点。
