首先你遇到的这个情况，本质是浏览器对定时器的隐形限制和事件循环的调度逻辑导致的：

• 定时器根本达不到1ms的间隔：根据HTML标准，当定时器嵌套超过5层后，浏览器会强制把最小间隔拉到4ms；就算是第一次调用，几乎所有现代浏览器也不会真的给你1ms的间隔——这是浏览器为了平衡性能和功耗做的优化。所以你写的setInterval(() => { tick += 1; }, 1)，实际执行间隔大概是4ms左右，1秒下来刚好约250次，这就是tick值和移动距离只有预期1/4的原因。
• 事件循环会拖慢回调执行：setInterval的回调是扔进事件队列里的，只有当主线程空闲时才会跑。如果主线程在处理渲染、其他脚本，这个回调就会被延迟，实际间隔会比4ms还大，进一步让tick更新次数不够。
  另外两个定时器是完全异步的，打印的那个只是每隔1秒取一次当前tick，自然会看到它是250的倍数。

做游戏/动画场景，requestAnimationFrame才是正确的打开方式——它会和浏览器的渲染帧同步触发（一般60次/秒，约16.6ms一次），既能保证画面流畅，又能完美避开定时器的坑。而且我们可以通过计算**时间差（deltaTime）**来确保移动速度精准，不依赖回调执行次数。

改好的代码示例： #

let lastTime = performance.now();
let position = 0; // 代替原来的tick，记录当前位置

function updatePosition(currentTime) {
  // 计算两次回调之间的时间差（毫秒）
  const deltaTime = currentTime - lastTime;
  lastTime = currentTime;

  // 预期速度是1000px/秒，用时间差计算该移动的距离
  // 公式：距离 = 速度（px/秒） * 时间（秒） → 1000 * (deltaTime/1000) = deltaTime
  position += deltaTime;

  // 这里可以写入更新游戏画面位置的逻辑
  console.log(`当前位置：${Math.round(position)}`);

  // 继续请求下一帧，形成动画循环
  requestAnimationFrame(updatePosition);
}

// 启动动画循环
requestAnimationFrame(updatePosition);

// 如果需要每秒打印一次位置快照，单独加个定时器即可
setInterval(() => {
  console.log(`每秒快照位置：${Math.round(position)}`);
}, 1000);

为啥这个方案靠谱？ #

• 与渲染同步：requestAnimationFrame的回调会在浏览器准备渲染下一帧时执行，不会出现定时器和渲染不同步导致的卡顿、跳帧问题。
• 速度绝对精准：不管浏览器帧率是60还是因为性能问题降到30，通过deltaTime计算移动距离，最终速度都会稳稳保持1000px/秒的预期值。
• 资源友好：如果页面切换到后台，requestAnimationFrame会自动暂停执行，不会白白消耗CPU和电量，这是定时器做不到的优势。

要是非得用定时器怎么办？ #

如果因为某些限制必须使用定时器，那也别每次固定加1，一定要基于时间差来计算更新量，比如：

let lastTime = Date.now();
let position = 0;

setInterval(() => {
  const currentTime = Date.now();
  const deltaTime = currentTime - lastTime;
  lastTime = currentTime;

  position += deltaTime; // 保持1px/ms的速度，和预期一致
  console.log(`当前位置：${Math.round(position)}`);
}, 1);

但还是要提醒你，这个方案不如requestAnimationFrame适合做动画，因为定时器的执行时机和浏览器渲染不同步，很容易出现画面不流畅的情况。

内容的提问来源于stack exchange，提问作者Eric