关键在“动得准不准”“格式对不对”“时区有没有坑”：date取本地时间而非utc，多时区用户显示不同；统一时区需手动加偏移；tolocaletimestring()省事但要注意参数与兼容性；getmonth()需+1；setinterval有延迟风险，应每次重取当前时间。
直接用 setInterval 配合 Date 对象就能实现，但关键不在“能不能动”，而在“动得准不准”“格式对不对”“时区有没有坑”。
为什么 new Date() 显示的时间可能和你预期不一致
Date 默认取的是用户本地系统时间，不是服务器时间，也不是 UTC。如果你的页面面向多时区用户（比如后台管理系统），看到的“当前时间”其实是各自电脑设置的时区时间。例如：北京用户看到的是东八区时间，而美国西海岸用户看到的是 PDT（UTC-7），同一秒显示的小时数差 15 小时。
- 若需统一展示某一时区（如北京时间），不能只靠
toLocaleString("zh-CN")，它仍受用户系统设置影响；应手动加偏移：new Date(Date.now() + 8 * 60 * 60 * 1000) -
toISOString()返回的是 UTC 时间字符串（带Z），直接显示会比北京时间晚 8 小时，别误当本地时间用 - 移动端某些旧 Android 浏览器对
toLocaleString的参数支持不全，hour12: false可能被忽略，导致出现 AM/PM
用 toLocaleTimeString() 快速上线但要注意参数
这是最省事的方案，适合内部工具页或对格式要求不严格的场景。它自动适配用户语言和地区习惯，比如中文环境默认“上午 10:41:22”，英文环境可能是 “10:41:22 AM”。
- 强制 24 小时制：传入
{ hour12: false }，否则 iOS Safari 默认用 12 小时制 - 只显示时间不显示日期：用
toLocaleTimeString("zh-CN", { hour12: false })，别错用成toLocaleString - 避免频繁重排：更新时用
textContent而非innerHTML，防止意外解析 HTML 字符
手动拼接格式时 getMonth() 必须加 1
getMonth() 返回的是 0–11，不是 1–12。这是前端开发里最常踩的“月份错位”坑，一月显示成 0 月，十二月显示成 11 月。
- 正确写法：
const month = now.getMonth() + 1 - 补零别漏：小时、分钟、秒都要
.toString().padStart(2, "0")，否则 9:5:3 会变成 "9:5:3" 而非 "09:05:03" - 年份别用
getYear()：已废弃，返回的是距 1900 年的偏移值，2026 年返回 126
setInterval(…, 1000) 实际刷新间隔可能大于 1 秒
JavaScript 是单线程的，如果页面正在执行长任务（比如渲染大量 DOM、运行复杂计算），setInterval 的回调会被推迟执行，导致时钟“跳秒”或卡顿 2–3 秒才更新一次。
- 更稳的做法：在每次回调中用
new Date()重新取当前时间，而不是靠计数器累加 - 避免内存泄漏：页面卸载前记得
clearInterval，尤其 SPA 中组件反复挂载/卸载时 - 精度要求高？别用
setInterval：改用requestAnimationFrame配合时间差计算，但普通时钟没必要
真正麻烦的不是让时间动起来，而是当用户开着网页过了一夜、切到后台又切回来、或者刚从休眠唤醒时，那个“当前时间”是否还能准确反映此刻——这取决于你用的是 Date.now() 还是缓存了初始时间再做加法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
