最可靠的时间显示方案是用 requestanimationframe + 时间差判断更新、手动提取日期字段并 padstart 格式化、同步设置 time 标签的 datetime 属性、监听页面可见性强制刷新，避免 setinterval 和 tolocalestring 的兼容性与精度问题。
直接用 setInterval 每秒调用 new Date() 并写入 DOM 是最常用也最容易出错的起点——它能跑起来，但秒针跳动不稳、时区错乱、首次加载空白、移动端后台冻结后时间错位等问题，基本都源于没处理好执行时机和格式边界。
setInterval 更新时间时秒数跳变或卡顿
浏览器主线程繁忙时，setInterval 不保证准时执行。比如页面有长任务，本该在 10:26:01.000 触发的更新可能拖到 10:26:01.800 才执行，导致视觉上“跳秒”甚至漏秒。
- 改用
requestAnimationFrame+ 时间差判断：只在真实秒数变化时更新 DOM，避免无效重绘 - 每次更新前计算当前毫秒数与上一次的差值，若 ≥1000ms 再刷新，不依赖定时器精度
- 初始渲染必须手动调用一次函数，否则首屏为空
- 别用字符串拼接后塞进
innerHTML，优先用textContent防 XSS 且更快
toLocaleString 本地化格式在不同设备显示不一致
toLocaleString('zh-CN') 看似方便，但 iOS Safari 对 hour12: true 的处理和 Chrome 不同，某些安卓 WebView 会忽略 month: 'long' 直接输出数字，导致“2026年8月26日”变成“2026/8/26”。
- 关键字段（年月日、时分秒）全部手动提取 +
padStart(2, '0')，不依赖 locale 行为 - 星期几用数组映射：
['星期日', '星期一', ..., '星期六'][date.getDay()]，稳定可控 - 需要 ISO 格式存档时，用
date.toISOString().slice(0, 19).replace('T', ' ')，比 locale 更可靠
time 标签加 datetime 属性却不起作用
<time id="clock"></time> 本身不会自动更新，datetime 属性也不会被 JS 自动同步。很多人写了标签，但 JS 里只改了 textContent，忘了同步 dateTime 属性，导致语义信息丢失。
- 更新文本的同时，必须显式设置：
el.dateTime = date.toISOString() -
dateTime属性名是小写dateTime，不是datetime或DATETIME，大小写敏感 - 如果只需语义化，不用动态更新，直接静态写死：
<time datetime="2026-08-26T10:26">2026年8月26日</time>
移动端切到后台再切回，时间停止或跳变严重
大多数浏览器在标签页不可见时会节流 setInterval，最低降到 1s 一次甚至更低；而 requestAnimationFrame 在后台直接暂停。结果就是切回来时，时间可能卡在几秒前，或一次性补跳多秒。
- 记录上一次更新的时间戳（
performance.now()或Date.now()），每次执行时对比真实经过时间 - 若间隔远大于 1000ms（如 > 3000ms），说明页面刚唤醒，应重新生成完整时间，而不是累加
- 监听
visibilitychange事件，在document.hidden === false时立即强制刷新一次
真正难的不是让时间动起来，而是让它在各种网络、系统、设备组合下都保持“可信”——秒数不跳、时区不错、语义不丢、后台不卡。这些细节不写进代码里，只靠 setInterval + toLocaleString 堆出来的东西，上线后大概率会在某个用户手机上露馅。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
