应使用时间戳校准法而非固定毫秒间隔：记录起始时间，每次渲染时用date.now()计算剩余时间，每100ms更新一次，并结合page visibility api处理页面失焦、requestanimationframe实现高精度计时、服务端时间兜底防篡改。
用 setInterval 实现基础倒计时，但别直接写死毫秒数
HTML5 本身不提供内置计时器组件，所有倒计时/计时功能都依赖 JavaScript 的 setInterval 或 setTimeout。直接写 setInterval(() => { sec-- }, 1000) 看似可行，但实际会因任务队列延迟、页面失焦暂停、JS 执行阻塞等问题导致误差累积——5 分钟后可能差 3–8 秒。
更可靠的做法是记录起始时间戳，每次渲染时计算剩余毫秒数：
let startTime = Date.now();
let durationMs = 5 * 60 * 1000; // 5分钟
<p>function updateTimer() {
const elapsed = Date.now() - startTime;
const remaining = Math.max(0, durationMs - elapsed);
const mins = Math.floor(remaining / 60000);
const secs = Math.floor((remaining % 60000) / 1000);
document.getElementById('timer').textContent = <code>${mins}:${secs.toString().padStart(2, '0')}</code>;</p><p>if (remaining <= 0) {
clearInterval(timerId);
}
}</p><p>const timerId = setInterval(updateTimer, 100); // 每100ms校准一次，平衡精度与性能- 用
Date.now()而非new Date().getTime()，前者更快更轻量 - 间隔设为
100而非1000，避免用户看到“跳秒”；人眼对 100ms 级更新无感，但能保证显示值始终准确 - 务必在结束时调用
clearInterval(timerId)，否则定时器持续运行，造成内存泄漏
页面后台运行时倒计时暂停？用 Page Visibility API 补救
Chrome/Firefox/Safari 在标签页不可见时会降频甚至暂停 setInterval，导致倒计时“卡住”。用户切回页面才发现已超时 2 分钟。
立即学习“前端免费学习笔记（深入）”；
用 document.visibilityState 监听页面可见性，在隐藏时暂停逻辑，在显示时重新校准：
let isPaused = false;
let pausedAt = 0;
<p>document.addEventListener('visibilitychange', () => {
if (document.hidden) {
isPaused = true;
pausedAt = Date.now();
} else if (isPaused) {
isPaused = false;
startTime += Date.now() - pausedAt; // 补上挂起时间
}
});- 不要依赖
blur/focus事件——它们在 iframe、弹窗、开发者工具打开时也会误触发 -
visibilitychange是唯一被所有现代浏览器稳定支持的页面可见性检测机制 - 补时间不能简单加固定值，必须用
Date.now()计算真实挂起时长
需要高精度计时（如秒表）？避开 setInterval 改用 requestAnimationFrame
当倒计时用于运动动画同步、音频节拍或实验室级计时场景时，setInterval 的抖动（±10–30ms）不可接受。此时应改用 requestAnimationFrame 驱动，它与屏幕刷新率绑定（通常 60fps），误差可压到 ±1ms 内。
let startTime = Date.now();
let lastTime = startTime;
let elapsed = 0;
<p>function tick(timestamp) {
if (!lastTime) lastTime = timestamp;
const delta = timestamp - lastTime;
elapsed += delta;
lastTime = timestamp;</p><p>const displaySec = (elapsed / 1000).toFixed(2);
document.getElementById('stopwatch').textContent = displaySec;</p><p>if (isRunning) requestAnimationFrame(tick);
}-
requestAnimationFrame不受页面是否可见影响，但会在页面完全冻结（如系统休眠）时停止——这反而是合理行为 - 必须用
timestamp参数（而非Date.now()）计算增量，它是浏览器提供的高精度单调时间源 - 注意：它不自动循环，需手动递归调用
requestAnimationFrame(tick)
倒计时结束要触发动作？别只靠定时器，加一层服务端时间兜底
纯前端倒计时最大的风险是用户篡改本地时间或设备时钟。比如把系统时间调快 1 小时，就能绕过 30 分钟答题限制。
关键操作（如提交、解锁、支付）必须和服务端时间比对。前端只负责 UI 提示，真正判断依据是服务端返回的 expires_at 时间戳：
// 假设接口返回 { expires_at: "2024-06-15T14:30:00Z" }
const serverExpires = new Date(response.expires_at).getTime();
<p>function checkDeadline() {
const now = Date.now();
const remaining = Math.max(0, serverExpires - now);
if (remaining <= 0) {
alert('已超时，请刷新重试');
return false;
}
return true;
}- 前端倒计时显示可以继续用本地时间（体验好），但“是否允许操作”的判断必须查
serverExpires - 服务端时间要用 UTC 格式（带
Z后缀），避免时区解析歧义 - 首次加载时就请求一次服务端时间，用它校准本地
Date.now()偏差，能进一步提升精度
前端倒计时看着简单，真正难的是处理页面失焦、时钟篡改、高帧率同步、服务端一致性这些边缘情况。多数项目卡在“能跑”和“可靠”之间，差的就是这几行校准和兜底逻辑。
