动态显示时间本质是将客户端本地时钟转化为可读、可维护、可交互的ui元素，解决信息同步问题；写死时间无法实时更新，导致脱节与逻辑失效；setinterval每秒更新最稳妥但需注意dom就绪、安全调用、节流及清理；高精度场景宜用requestanimationframe并手动控制更新时机；格式化须补零或用tolocaletimestring避免不美观；边界条件如后台切换、网络延迟、锁屏唤醒等影响准确性与性能。
动态显示时间不是为了“炫技”，而是解决真实场景里的信息同步问题：用户需要知道操作发生的准确时刻，系统需要标记事件时间戳，界面需要响应状态变化。它本质是把客户端本地时钟变成可读、可维护、可交互的 UI 元素。
为什么不能直接写死 <span>10:51:25</span>？
写死时间在页面加载后就失效了。哪怕只过 1 秒，它就和实际时间脱节；用户刷新页面才能看到新值，体验断裂；更重要的是，它无法支撑任何依赖实时性的逻辑，比如倒计时、会话超时提示、日志时间标注等。
常见错误现象包括：
- 时间停在页面加载那一刻，再也不动
- 用
setTimeout递归但没清前一次定时器，导致多个定时器叠加执行 - 把
new Date()放在函数外，结果每次更新都用同一个时间对象
setInterval 每秒更新是最稳妥的选择吗？
对绝大多数网页来说，是的——它简单、兼容性好、语义明确。但要注意几个关键点：
- 必须确保 DOM 已就绪再启动，否则
document.getElementById('clock')返回null - 不要用字符串形式传入
setInterval（如setInterval("update()", 1000)），这会触发eval，有安全和性能隐患 - 如果页面长时间后台运行（标签页切换），
setInterval仍会执行，但浏览器可能节流到最低 1 秒甚至更慢，造成跳秒 - 记得保存返回的 timer ID，后续可能需要
clearInterval主动清理（比如组件卸载时）
什么时候该换用 requestAnimationFrame？
当你需要更高精度或更顺滑的视觉表现时，比如做秒表、倒计时动画、或与 CSS 动画帧率对齐的数字翻转效果。它不保证“每秒执行 1 次”，而是“每次浏览器准备重绘前执行一次”，所以更省资源、不易卡顿。
但它有个隐藏前提：你得自己判断“是否真该更新”。因为帧率不固定（60fps 或更低），不能简单地每次调用都写 DOM。典型做法是记录上一次更新的时间戳，仅当秒数变化才触发 DOM 更新：
function clockTick() {
const now = new Date();
if (now.getSeconds() !== lastSecond) {
el.textContent = now.toLocaleTimeString();
lastSecond = now.getSeconds();
}
requestAnimationFrame(clockTick);
}
注意：这个方案在页面不可见时，requestAnimationFrame 会被暂停，反而比 setInterval 更省电。
格式化时间时最容易忽略的细节
月份、日期、小时、分钟、秒这些值都不是天然带前导零的：getMonth() 返回 0–11，getDate() 可能返回 1–31，getHours() 是 0–23。直接拼接会导致 "2026-8-26 9:5:2" 这种难看格式。
推荐做法是统一用 String(num).padStart(2, '0') 补零，或者更简洁地用 toLocaleTimeString() 配合选项：
new Date().toLocaleTimeString('zh-CN', {
hour12: false,
hour: '2-digit',
minute: '2-digit',
second: '2-digit'
}) // → "10:51:25"
别硬写正则或手撕格式化函数——现代浏览器的 Intl API 已足够可靠，且支持多语言、多时区。
真正难的不是让时间动起来，而是让它在各种边界条件下依然准确、轻量、不干扰主线程。比如用户切到其他标签页再回来，时间是否跳变？网络差的时候会不会卡住？移动端锁屏唤醒后能否立刻同步？这些才是实操中容易被忽略的复杂点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
