Web特效011—Web特效的定义与边界为什么忽快忽慢：时间、频率与采样的秘密

Web特效011---Web特效的定义与边界为什么忽快忽慢：时间、频率与采样的秘密

时间是 Web 特效里最容易被忽略、却决定运动是否自然的变量。一个动画并不是"每帧移动固定距离"这么简单：浏览器的刷新频率、设备性能和当前负载都会让相邻帧之间的间隔发生变化。如果把位移直接写成每帧加 1，帧率下降时动画就会变慢；如果忽略采样频率，快速运动还可能出现跳跃、闪烁或漏看。本文将从时间间隔（delta time）、帧率与刷新频率的关系出发，解释为什么动画应根据经过的真实时间更新状态；再进一步介绍采样、插值、固定时间步长和时间平滑等方法，说明它们如何影响运动的稳定性、响应速度与视觉连续性。同时，文章还会讨论 requestAnimationFrame() 的使用边界、低帧率设备上的降级策略，以及如何在性能和观感之间取舍，帮助读者把"会动的画面"变成速度一致、节奏可控、适应不同设备的 Web 特效。

一、动画为什么不能只按"每帧移动一点"来写

1. "每帧加 1"其实偷偷绑定了帧率

很多动画的第一版都会这样写：每次循环让物体的 x 坐标增加一个固定数字，然后重新绘制。代码很直观，但它表达的不是"物体每秒移动多少"，而是"物体每渲染一帧移动多少"。这两个意思只有在帧率始终不变时才相同。

js 复制代码

let x = 0;

function frame() {
  x += 1;
  drawCircle(x);
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

假设这段代码在 60 FPS 下运行，一秒大约执行 60 次，物体移动约 60 个单位；如果设备只能维持 30 FPS，它一秒只移动约 30 个单位。用户看到的不是"设备变慢但物体仍保持速度"，而是物体真的慢了一半。

2. 帧率变化来自哪里

浏览器并不能保证每一帧都在完全相同的时间完成。显示器可能以 60 Hz、90 Hz、120 Hz 或其他频率刷新；JavaScript 线程可能被复杂计算、布局、垃圾回收或用户交互占用；GPU 也可能因为高分辨率、透明叠加和复杂着色而延迟完成。

因此，相邻两帧之间的间隔可能是 16.7 毫秒，也可能突然变成 25 毫秒、40 毫秒甚至更长。动画如果只根据"这是第几帧"更新，就会把这些时间差误认为相同的时间长度，导致速度随设备负载变化。

3. 用"速度 × 时间"描述运动

更可靠的做法是先定义物体的真实速度，再根据两帧之间经过的时间计算位移。基本公式很简单：

本帧位置 = 上一帧位置 + 速度 × 时间间隔

如果速度单位是"每秒移动 120 个像素"，而本帧距离上一帧经过了 0.016 秒，那么这次应该移动 120 × 0.016 = 1.92 个像素。下一帧即使间隔变成 0.025 秒，也应该移动 3 个像素，从而尽量保持每秒 120 像素的平均速度。

js 复制代码

let x = 0;
const speed = 120; // 每秒移动 120 个 CSS 像素
let previousTime = 0;

function frame(time) {
  const deltaSeconds = previousTime === 0
    ? 0
    : (time - previousTime) / 1000;
  previousTime = time;

  x += speed * deltaSeconds;
  drawCircle(x);
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

requestAnimationFrame() 提供的时间戳通常以毫秒为单位，所以进入公式前要转换为秒。第一次执行时没有上一帧时间，可以把间隔设为 0，避免物体突然跳动。

4. 速度一致不等于画面绝对相同

时间相关更新只能保证运动模型不依赖某个固定帧率，不能让低帧率设备凭空显示更多中间画面。60 FPS 时，用户会看到更密集的采样；30 FPS 时，相邻位置之间的距离更大，视觉上仍可能感觉到跳跃。也就是说，时间模型解决的是"跑得快慢不一致"，而不是"帧数不足"本身。

这一区分非常重要：如果问题是速度变化，应改用时间间隔；如果问题是渲染负载过高，则还要减少对象数量、降低计算复杂度或调整画布分辨率。动画的正确性和画面的流畅度相关，却不是同一个问题。

5. 先确定单位，动画才有可控的节奏

实际项目中，位置可以用 CSS 像素，角度可以用弧度，透明度通常在 0 到 1 之间，速度则应明确是"每秒多少单位"。把这些单位写进变量命名或注释，有助于避免把毫秒当秒、把每帧增量当速度等错误。

例如，velocityX = 120 可以表示每秒 120 个像素，而不是每帧 120 个像素；duration = 0.8 可以表示 0.8 秒，而不是 0.8 毫秒。时间单位一旦统一，后续的缓动、弹簧、粒子和路径运动都能建立在同一套规则上。

下一节将进一步拆开时间间隔、帧率和显示器刷新频率，看看它们之间到底是什么关系，以及为什么同一段动画在不同设备上会呈现不同的采样效果。

二、时间间隔与帧率：运动速度到底由谁决定

1. FPS 和时间间隔是同一件事的两种观察方式

帧率（FPS，frames per second）表示一秒钟内完成了多少帧；时间间隔（delta time 或 dt）表示相邻两帧之间经过了多少时间。两者大致互为倒数：

dt ≈ 1 / FPS

60 FPS 时，每帧约间隔 1 / 60 秒，也就是 16.7 毫秒；30 FPS 时，每帧约间隔 33.3 毫秒。FPS 是从"一秒能画几张"观察性能，dt 是从"这一帧距离上一帧多久"观察运动。更新动画时，后者通常更直接。

2. 刷新率规定了"机会"，帧率反映了"实际完成量"

显示器的刷新率以 Hz 表示，例如 60 Hz、120 Hz，代表屏幕每秒有多少次刷新机会。浏览器的 requestAnimationFrame() 通常会尽量配合显示刷新，但它并不保证每次机会都能按时完成一帧。如果 JavaScript、布局、绘制或 GPU 处理超时，某个刷新周期就可能被错过。

所以，120 Hz 屏幕不等于页面必然达到 120 FPS。刷新率是上限和节奏参考，实际帧率还取决于整条渲染链路。反过来，低帧率也不一定意味着动画逻辑错误，可能只是当前设备没有足够时间完成这一帧。

3. 用时间戳测出这一帧真正经过了多久

requestAnimationFrame() 的回调参数是浏览器提供的高精度时间戳。用当前时间减去上一帧时间，就能得到本帧的间隔。下面的示例同时计算 dt 和近似 FPS，并限制显示的小数位，便于在调试面板中观察：

js 复制代码

let previousTime = 0;
let frameCount = 0;
let secondStart = 0;

function frame(time) {
  const dt = previousTime === 0 ? 0 : (time - previousTime) / 1000;
  previousTime = time;

  frameCount += 1;
  if (time - secondStart >= 1000) {
    console.log(`FPS: ${frameCount}, dt: ${dt.toFixed(4)} s`);
    frameCount = 0;
    secondStart = time;
  }

  updateScene(dt);
  drawScene();
  requestAnimationFrame(frame);
}

requestAnimationFrame((time) => {
  secondStart = time;
  frame(time);
});

一次 dt 只能说明相邻两帧的间隔，不能代表长期稳定的帧率。实际性能分析通常还会观察一段时间内的平均值、最小值和最大值，因为偶发的长帧往往比平均 FPS 更能解释卡顿。

4. 速度由模型决定，帧率只决定采样密度

假设一个物体的速度是每秒 200 像素，它在 60 FPS 下每帧移动约 3.33 像素，在 30 FPS 下每帧移动约 6.67 像素。两种情况下，一秒后的理论位置都应接近起点加 200 像素，只是 30 FPS 的中间采样点更少。

js 复制代码

function updateObject(object, dt) {
  object.x += object.velocityX * dt;
  object.y += object.velocityY * dt;
}

这种写法把物理量和显示频率分开：velocityX 是每秒的速度，dt 是这一次实际经过的时间。对于匀速移动、旋转和透明度变化，它通常足够可靠；对于碰撞、弹簧和刚体模拟，还需要进一步考虑大时间步长带来的数值稳定性。

5. 长帧为什么需要保护

当页面切到后台、电脑从睡眠中恢复，或主线程突然被阻塞时，下一次回调的时间戳可能与上一帧相差几百毫秒。如果直接把这个巨大 dt 代入位置、弹簧或粒子公式，物体可能瞬间穿过边界，甚至让数值计算爆炸。

常见的保护方式是给 dt 设置上限：

js 复制代码

function updateWithSafeDelta(state, dt) {
  const safeDt = Math.min(dt, 0.05); // 最多按 50 ms 更新一次
  state.x += state.speed * safeDt;
}

这会牺牲一小段"真实经过的时间"，换取动画不会因一次异常长帧而失控。更严格的物理模拟则可以把长帧拆成多个固定小步执行。下一节将继续讨论采样与插值，解释连续运动为什么会在屏幕上变成离散的一帧帧画面。

三、采样与插值：连续运动为什么会变成一帧一帧的画面

1. 屏幕看到的是时间上的"快照"

现实中的运动可以被看成连续变化：物体在任意时刻都有一个位置。但屏幕不是持续记录每个瞬间，而是在某些时间点刷新并展示一张画面。渲染器在 t₀、t₁、t₂ 等时刻计算状态，这个过程就是采样（sampling）。用户看到的是一串按时间排列的快照，而不是运动本身的无限连续版本。

如果相邻快照之间的状态变化足够小，大脑会把它们组织成连续运动；如果间隔太大，物体就会像跳格一样移动。这也是"动画已经按时间更新"却仍然不够顺滑的原因：时间模型保证位置计算合理，采样密度仍由实际帧率决定。

2. 采样不足会产生跳跃、闪烁和混叠

当物体移动得很快，而画面采样得很少时，相邻两帧之间的距离会变大。小物体可能在一帧出现在左边，下一帧直接出现在右边，中间路径没有被屏幕记录；细密纹理或周期性图案还可能在不同帧之间改变明暗和形状，产生闪烁、摩尔纹或方向错误的视觉效果，这类现象通常称为混叠（aliasing）。

采样问题不只来自低 FPS。即使平均帧率很高，只要时间间隔忽大忽小，运动的视觉节奏也会不稳定。相机快速移动、粒子高速飞行和细线缩放尤其容易暴露采样不足，因此常需要配合运动模糊、抗锯齿、尺寸限制或更稳定的时间步长。

3. 插值是在两个已知状态之间补出中间值

插值（interpolation）并不是凭空增加真实帧，而是根据已有的起点和终点估算中间状态。最常见的线性插值公式是：

value = start + (end - start) × progress

其中 progress 通常在 0 到 1 之间。位置、颜色、透明度和角度都可以使用这个模型，但角度要注意跨越 0 与 2π 时的最短路径问题。

js 复制代码

function lerp(start, end, progress) {
  const t = Math.max(0, Math.min(1, progress));
  return start + (end - start) * t;
}

function interpolatePoint(from, to, progress) {
  return {
    x: lerp(from.x, to.x, progress),
    y: lerp(from.y, to.y, progress)
  };
}

const point = interpolatePoint(
  { x: 20, y: 40 },
  { x: 220, y: 140 },
  0.5
);
// point 是 { x: 120, y: 90 }

如果动画使用固定的起点和终点，progress 可以由经过时间除以总时长得到；如果是实时运动，则通常直接用速度乘以 dt 更新状态。两者都在估算状态变化，但应用场景不同：插值更适合已知区间的过渡，速度积分更适合持续运动。

4. 线性插值不一定等于自然运动

线性插值会让数值以恒定比例变化，适合匀速移动和基础渐变，但很多界面动画需要加速、减速或弹性回弹。此时可以先对进度 t 应用缓动函数，再进行插值：

js 复制代码

function easeOutCubic(t) {
  const clamped = Math.max(0, Math.min(1, t));
  return 1 - Math.pow(1 - clamped, 3);
}

const rawProgress = elapsed / duration;
const visualProgress = easeOutCubic(rawProgress);
const x = lerp(startX, endX, visualProgress);

缓动改变的是"经过区间时如何分配变化"，不是采样频率。低帧率设备上，缓动后的物体仍可能从一个较远位置跳到另一个较远位置；如果同时需要稳定的模拟和自然的显示，可以让物理状态按固定步长更新，再用插值结果在渲染时补出当前显示位置。

5. 不要把插值误认为增加了真实细节

插值只能利用已有信息推断中间状态。如果输入数据本身错误，或者物体在两帧之间发生了碰撞、遮挡和拓扑变化，简单插值可能得到一个看似平滑却不符合事实的结果。例如，直接在障碍物两侧插值位置，可能让物体穿过墙；直接对两张差异很大的图像做颜色插值，也无法还原真实的运动轨迹。

因此，插值应放在正确的层级：先用规则或物理模型得到可信状态，再用插值改善显示连续性；对于必须严格响应的输入，不能为了平滑而引入过大的显示延迟。下一节将回到浏览器的动画调度，看看 requestAnimationFrame() 如何把这些时间和采样概念接入实际循环。

四、`requestAnimationFrame()` 如何驱动一条稳定的动画循环

1. 它预约的是下一次绘制机会

requestAnimationFrame()（简称 rAF）不是一个"尽快重复执行"的定时器，而是向浏览器请求在下一次合适的屏幕更新前调用函数。浏览器会把回调安排在绘制窗口附近，让 JavaScript 的更新、页面绘制和显示刷新更容易对齐。

js 复制代码

function frame(time) {
  updateScene(time);
  drawScene();
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

把下一次 rAF 放在当前回调的末尾，循环才会继续；如果只调用一次，动画只会更新一帧。浏览器标签页不可见或系统资源紧张时，回调频率也可能降低甚至暂时暂停，因此不能把 rAF 的调用次数当作经过时间。

2. 回调时间戳是动画循环的时间基准

rAF 回调接收的 time 可以用来计算两帧之间的间隔。更新逻辑接收 dt，绘制逻辑读取更新后的状态，这样动画循环的职责会更加清晰：

js 复制代码

let previousTime = null;
let animationId = 0;

function frame(time) {
  const dt = previousTime === null
    ? 0
    : Math.min((time - previousTime) / 1000, 0.05);
  previousTime = time;

  updateScene(dt);
  drawScene();
  animationId = requestAnimationFrame(frame);
}

animationId = requestAnimationFrame(frame);

第一次回调没有上一帧时间，所以把 dt 设为 0。这里把最大间隔限制为 50 毫秒，是为了避免页面暂停后恢复时产生一次过大的状态跳跃；具体上限应根据动画类型调整。

3. 更新和绘制要分成两个阶段

稳定循环通常遵循"读取输入 → 更新状态 → 绘制画面"的顺序。更新阶段只改变位置、速度、进度和生命周期；绘制阶段根据当前状态设置颜色、变换和资源，然后提交绘制命令。不要在绘制函数里偷偷修改物理状态，否则同一个对象被绘制两次时可能得到两个不同结果，排查会变得困难。

js 复制代码

const state = { x: 40, velocity: 120 };

function updateScene(dt) {
  state.x += state.velocity * dt;
}

function drawScene() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  ctx.fillRect(state.x, 40, 24, 24);
}

这种分离也方便以后切换渲染后端：同一份状态可以交给 Canvas 2D、WebGL 或其他绘制器，而不必把时间逻辑和图形 API 调用全部重写。

4. 页面不可见时要暂停不必要的工作

浏览器通常会降低后台页面的动画调度频率，但应用仍应主动管理自己的动画生命周期。对于不需要后台继续计算的特效，可以监听 visibilitychange，页面隐藏时停止循环，重新可见时重置时间基准再恢复。

js 复制代码

let running = false;

function startAnimation() {
  if (running) return;
  running = true;
  previousTime = null;
  animationId = requestAnimationFrame(frame);
}

function stopAnimation() {
  running = false;
  cancelAnimationFrame(animationId);
}

document.addEventListener('visibilitychange', () => {
  if (document.hidden) stopAnimation();
  else startAnimation();
});

恢复时将 previousTime 设为 null，可以避免把后台停留的整段时间误算成下一帧的 dt。如果特效需要保持真实世界时间，例如倒计时或进度同步，则应另外保存绝对时间，不要依赖后台期间的帧数。

5. 结束动画时取消回调并释放资源

每次 requestAnimationFrame() 都会返回一个请求编号。组件卸载、弹窗关闭或场景切换时，应调用 cancelAnimationFrame() 取消尚未执行的回调，并清理事件监听器、纹理、缓冲区等资源。否则旧循环可能继续更新已经不存在的 DOM 或渲染上下文。

最终，一个可靠的 rAF 循环应满足四点：由浏览器提供的时间戳驱动，更新与绘制职责分离，对异常长帧有保护，页面不可见或场景结束时能暂停和取消。下一节将进一步介绍固定时间步长与时间平滑，处理物理模拟和突发卡顿带来的稳定性问题。

五、固定时间步长与时间平滑：怎样处理卡顿和突发延迟

1. 为什么变量 `dt` 会让模拟结果不稳定

按真实 dt 更新适合匀速移动，但在碰撞、弹簧、摩擦和粒子系统中，公式对时间步长很敏感。同一段时间如果一次用 0.1 秒更新，或分成十次用 0.01 秒更新，数值积分结果可能不同。步长越大，物体越容易穿过障碍，弹簧也可能出现过冲甚至发散。

这不是 requestAnimationFrame() 的错误，而是显示采样与模拟计算承担了不同任务。显示帧的间隔天然会变化，模拟却希望每次都用可控的时间步长。因此，需要把"浏览器什么时候让我画"与"模拟推进多少时间"分开。

2. 固定时间步长让模拟使用同一把尺子

固定时间步长（fixed timestep）会规定模拟每次只推进一个固定时长，例如 1 / 60 秒。浏览器这一帧给了多少真实时间，就先存入累加器，再用若干次固定步长消耗它：

js 复制代码

const fixedStep = 1 / 60;
let accumulator = 0;
let previousTime = null;

function frame(time) {
  const elapsed = previousTime === null
    ? 0
    : Math.min((time - previousTime) / 1000, 0.25);
  previousTime = time;
  accumulator += elapsed;

  while (accumulator >= fixedStep) {
    updatePhysics(fixedStep);
    accumulator -= fixedStep;
  }

  drawScene();
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

这样，无论某次屏幕回调间隔是 12 毫秒还是 24 毫秒，物理更新都只接收固定的 16.7 毫秒。0.25 秒的上限用于避免页面长时间停顿后突然执行过多补偿步骤。

3. 累加器过载时要防止"死亡螺旋"

如果设备已经很慢，每帧用于更新和绘制的时间都超过固定步长，累加器就可能越积越多。程序为了追赶过去的时间而执行更多更新，更多更新又让下一帧更慢，最终形成"死亡螺旋"（spiral of death）。

工程上通常会限制单帧最多执行的固定步数：

js 复制代码

const maxStepsPerFrame = 5;
let steps = 0;

while (accumulator >= fixedStep && steps < maxStepsPerFrame) {
  updatePhysics(fixedStep);
  accumulator -= fixedStep;
  steps += 1;
}

if (steps === maxStepsPerFrame) {
  accumulator = 0;
}

丢弃一部分积压时间意味着模拟可能轻微跳过，但页面仍能恢复响应。对背景粒子或装饰性特效，这通常比让主线程持续追赶更合适；对必须精确的游戏或实验模拟，则应降低模拟复杂度、分离线程或采取更严格的同步方案。

4. 用渲染插值隐藏固定步长的离散感

固定步长让状态更新稳定，却可能让低帧率显示出现轻微跳动，因为渲染时看到的是两个模拟状态之间的某一个离散结果。累加器中剩余的时间可以换算为插值系数：

js 复制代码

const alpha = accumulator / fixedStep;
const visibleX = previousState.x * (1 - alpha) + currentState.x * alpha;
drawCircle(visibleX);

这里的 previousState 和 currentState 分别是上一个、当前固定步长完成后的状态。插值只改变显示位置，不改变物理状态，因此既保持了模拟的确定性，也让画面更连贯。需要注意，插值会让显示结果落后于最新模拟状态一个小步长；对要求极低延迟的指针跟随或交互反馈，不应盲目套用。

5. 时间平滑要服务于问题，而不是掩盖问题

有些视觉特效不需要严格的物理精度，只希望运动节奏不要因偶发长帧而突然改变。这时可以对 dt 做平滑，例如使用最近几次间隔的加权平均，或对速度和进度采用缓动。但平滑会引入滞后，也可能让真实的快速变化被压低，所以不能把它当作解决所有卡顿的万能滤镜。

可以这样选择：匀速移动使用真实 dt 并设置上限；物理模拟使用固定步长，必要时配合渲染插值；装饰性过渡可以使用平滑或缓动；任何类型都要限制单帧工作量，并在页面不可见时暂停。稳定的时间系统不是让每一帧都完美，而是在异常发生时让结果仍然可控。

到这里，011 的核心结论已经完整：帧率决定采样密度，时间间隔决定一次更新应推进多少，固定步长保证模拟稳定，插值和平滑改善显示连续性。实际项目应根据特效是匀速运动、界面过渡还是物理模拟，选择对应的时间模型。

六、从时间模型到实际特效：如何兼顾自然观感与设备性能

1. 先按特效类型选择时间模型

不同特效不需要同一种时间系统。简单的位移、旋转和透明度变化，使用真实 dt 更新即可；有碰撞、弹簧和重力的粒子系统，更适合固定时间步长；已知起点和终点的菜单展开、进度条和页面转场，可以使用总时长加插值；只负责装饰氛围的背景光斑，则可以牺牲部分精度换取更低的计算成本。

特效类型	推荐模型	主要原因
匀速移动、旋转	真实 `dt`	速度与帧率解耦
碰撞、弹簧、重力	固定时间步长	模拟结果更稳定
UI 过渡、进度动画	时长 + 插值/缓动	起点终点明确
背景粒子、装饰光效	`dt` 上限 + 降级	优先保证页面响应

先确定模型，再决定代码结构，通常比写完动画后再修复"不同设备速度不一样"更省时间。

2. 把性能预算写进动画设计

流畅不是一个脱离设备的固定数字，而是在目标设备上让每帧工作量保持可控。60 FPS 的理想帧间隔约为 16.7 毫秒，但这段时间还要分给 JavaScript、样式计算、布局、绘制、合成和浏览器其他任务。特效不应默认可以独占整个帧预算。

可以从三个方向减少压力：降低每帧更新的对象数量，减少重复的状态切换和绘制调用，降低全屏透明层、离屏纹理和高分辨率片元计算的面积。性能优化要用浏览器开发者工具验证，观察长帧、脚本耗时、绘制耗时和内存变化，而不是只凭肉眼猜测。

3. 为低性能设备准备分级降级

当设备无法稳定维持目标帧率时，可以逐级降低视觉成本：减少粒子数量，降低粒子更新频率，缩小特效覆盖范围，关闭昂贵的模糊和后处理，或改用 CSS 过渡和静态渐变。降级的原则是优先保留表达重点，例如按钮反馈和主要对象的运动应保留，远景装饰可以简化。

js 复制代码

function getQualityLevel(fps) {
  if (fps >= 55) return 'high';
  if (fps >= 35) return 'medium';
  return 'low';
}

function applyQuality(level, effect) {
  effect.maxParticles = level === 'high' ? 180 : level === 'medium' ? 90 : 35;
  effect.enableBlur = level === 'high';
}

质量等级不宜每帧来回切换，可以对 FPS 做短时间平均，并设置进入和退出阈值，避免画面在边界附近反复抖动。用户主动开启的高质量选项也应尊重，但要确保页面基本交互不会因此失去响应。

4. 让动画尊重页面状态和用户偏好

页面不可见时暂停不必要的 rAF 循环，能减少 CPU 使用和耗电；特效只在进入视口附近运行，能避免用户尚未看到的内容提前消耗资源。对于可能引起眩晕或视觉负担的连续运动，还应响应 prefers-reduced-motion，提供缩短、减弱或直接关闭动画的版本。

js 复制代码

const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

function getAnimationDuration(normalDuration) {
  return reduceMotion ? 1 : normalDuration;
}

无障碍设置不是性能优化的替代品，但它提醒我们：自然观感不等于运动越多越好。好的 Web 特效应当服务信息层级和交互反馈，而不是让用户被迫承受持续变化。

5. 一套可落地的最终检查清单

发布前可以按下面的顺序检查：动画位置是否使用了明确的时间单位；匀速运动是否通过 速度 × dt 更新；物理模拟是否限制了步长和单帧补偿次数；渲染插值是否只影响显示而没有篡改模拟状态；后台页面和组件卸载时是否能停止循环；低端设备是否有合理降级；用户减少动态效果的偏好是否得到尊重。

011 的核心结论可以收束为四句话：帧率决定画面采样密度，dt 决定当前帧应推进多少；固定时间步长让敏感的模拟保持稳定；插值与缓动改善显示连续性，但不能创造真实细节；性能和无障碍策略决定特效能否在真实设备上被舒适地使用。把这四层关系理清，动画就不再依赖某台机器的固定帧率，而会成为速度可控、异常可恢复、成本可管理的网页体验。

七、关于八荒启

八荒启是一家专注于交互体验产品与解决方案的品牌，持续探索交互技术在教育教学、产品展示、过程模拟、操作训练和数据可视化等场景中的应用。

我们不仅分享技术实现，也持续创作和沉淀交互动画、数字作品、开发教程、项目案例与行业解决方案，希望通过交互技术，让复杂事物变得更加容易理解、探索、操作和创造。

八荒启，专为交互动画而生

让复杂事物可探索、可操作、可反馈

如果你正在寻找交互作品、学习相关技术，或者希望把一个想法转化为可实际操作的交互项目，欢迎访问八荒启官网了解更多案例与服务。

官方网站：https://bahuangqi.com
主要内容：交互动画、3D 可视化、教育互动、仿真模拟与技术教程
定制服务：可通过官网提交需求或联系人工客服进行评估

感谢阅读。如果本文对你有所帮助，欢迎点赞、收藏和关注，我们会继续分享更多交互作品与项目实践。

Web特效011—Web特效的定义与边界为什么忽快忽慢：时间、频率与采样的秘密