不能只用 setinterval(() => { ... }, 1000)，因其存在三大隐患：页面后台运行时被浏览器节流导致跳秒；未校验 dom 元素存在性引发空引用错误；未清理定时器造成内存泄漏和时间错乱。
直接用 JavaScript 的 Date 对象 + setInterval 就能跑起来，但不处理时区、不防页面隐藏、不清理定时器，上线后大概率出问题。
为什么不能只写 setInterval(() => { ... }, 1000)
看似每秒更新一次很稳，实际有三个隐性坑：
一是页面切到后台时，setInterval 可能被浏览器节流（尤其 Chrome），导致时间卡住或跳秒；
二是没判断 DOM 元素是否存在，脚本提前执行或元素 id 写错，控制台报 Cannot set property 'textContent' of null；
三是没清除定时器，页面反复加载或 SPA 路由切换时，旧定时器还在跑，内存泄漏+时间乱跳。
实操建议：
- 用
document.getElementById前先做存在性判断，比如if (el) el.textContent = ... - 把
setInterval的返回值存成变量，后续配合visibilitychange事件清理：document.addEventListener('visibilitychange', () => { if (document.hidden) clearInterval(timerId); }) - 首次渲染别等
setInterval触发，手动调用一次更新函数，避免“加载中”卡住
toLocaleTimeString() 和手动拼接字符串的区别
前者靠浏览器本地化规则自动适配格式（比如中文系统输出“下午1:25:36”，美式输出“1:25:36 PM”），后者完全可控但要自己补零、算月份偏移、处理 AM/PM。如果你只需要“HH:MM:SS”，toLocaleTimeString('zh-CN', { hour12: false }) 更省事；如果必须固定为 2026-08-26 13:25:42 这种格式，就得手动调 getFullYear()、getMonth() + 1、padStart(2, '0')。
注意点：
-
getMonth()返回 0–11，不加 1 会把 8 月显示成 7 月 -
toLocaleTimeString()默认包含毫秒（部分浏览器），加{ fractionalSecondDigits: 0 }可去掉 - 服务器渲染页面时，
toLocaleString()显示的是用户本地时间，和服务器时间可能差几小时——关键业务得用服务端注入时间戳
要不要用 requestAnimationFrame 替代 setInterval
没必要为普通时钟换。它适合对帧率敏感的场景（比如倒计时动画、进度条联动），因为它的触发时机绑定屏幕刷新，不会出现“1000ms 定时器在 1020ms 才执行”的漂移。但实现上更麻烦：你要自己缓存上一秒的时间戳，每次进来比对 now.getSeconds() !== lastSec 才更新 DOM，否则每帧都刷反而浪费性能。
简单判断标准：
- 只要求“每秒变一次”，用
setInterval，加 visibilitychange 清理就够了 - 需要精确到毫秒级变化（如拍卖倒计时），或和 CSS 动画强同步，才值得上
requestAnimationFrame - 别为了“高级感”硬套——95% 的页面时钟，
setInterval更直白、更易 debug
时区问题最容易被忽略的点
new Date() 拿到的是用户本地时间，toISOString() 拿到的是 UTC 时间。如果你在页面里混用两者又不标注，比如用 toISOString().slice(0,19).replace('T',' ') 显示时间，用户在北京看到的会是 UTC+0 时间（比本地慢 8 小时），以为时间错了。
正确做法取决于需求：
- 展示“用户当前所在地时间”：直接用
new Date().toLocaleTimeString()，不碰时区参数 - 展示“服务器所在时区时间”：后端吐一个时间戳（如
1756214742000），前端new Date(1756214742000)实例化 - 展示多时区并列（如纽约/伦敦/东京）：用
Intl.DateTimeFormat，传{ timeZone: 'America/New_York' }等参数，别自己算偏移
真正难的不是代码怎么写，而是想清楚这个时间到底该以谁的视角为准——用户？服务器？还是某个固定时区？定错这点，后面所有格式化都是白忙。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
