toLocaleTimeString()更安全，因浏览器自动处理时区、12/24小时制、AM/PM及本地化细节，避免手动拼接漏补零、错用时区或兼容性问题；setInterval存在精度低、后台降频、跳秒等缺陷，推荐requestAnimationFrame+时间差校准方案。
直接用 setInterval 配合 new Date() 就能实时更新，但多数人卡在格式化和时区上。
为什么 toLocaleTimeString() 比手动拼接更安全
浏览器自动处理本地时区、12/24小时制、AM/PM、千位分隔符等细节，避免手写逻辑漏掉 getHours() 补零或夏令时偏移问题。比如中国用户不会意外显示成 UTC 时间，日本用户也不会错用英文缩写。
- 推荐写法：
new Date().toLocaleTimeString('zh-CN', { hour12: false, hour: '2-digit', minute: '2-digit', second: '2-digit' }) - 慎用手动拼接：
date.getHours() + ':' + date.getMinutes()—— 少了补零（如9:5）和时区转换，容易在 Safari 或低版本 Edge 中出错 - 注意：若需固定 UTC 时间，改用
toUTCString()并截取时间部分，别依赖toLocaleTimeString()的timeZone选项（兼容性差）
setInterval 的间隔设成 1000ms 仍有跳秒问题
因为 JS 定时器不精确，加上函数执行耗时、页面失焦暂停等因素，实际回调可能延迟几十毫秒，导致秒数“卡住”或“连跳”。尤其在后台标签页中，Chrome 会把间隔拉长到 1s 以上。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 解决办法：不用
setInterval倒推，改用requestAnimationFrame+ 时间差校准 - 简单可靠方案：每 100ms 触发一次，只在秒数真正变化时更新 DOM（减少重排）
- 示例逻辑：
function updateClock() { const now = new Date(); const seconds = now.getSeconds(); if (seconds !== lastSeconds) { el.textContent = now.toLocaleTimeString(...); lastSeconds = seconds; } requestAnimationFrame(updateClock); }
服务端时间不准时，前端怎么对齐
用户本地时间可能被手动修改，导致显示与服务器不一致。纯前端无法“纠正”系统时间，但可以估算偏差并补偿。
立即学习“前端免费学习笔记（深入）”；
- 首次加载时请求一次服务端时间（如 API 返回
timestamp），计算差值：serverTime - new Date().getTime() - 后续用
new Date().getTime() + offset得到逼近服务端的时间，再格式化显示 - 注意：offset 会随网络延迟漂移，建议每 5 分钟重新校准一次，避免累积误差超过 1 秒
- 不要用
Date.parse()解析服务端字符串时间——不同浏览器对格式容忍度不同，优先用时间戳
真正麻烦的不是“怎么显示”，而是“什么时候该信哪个时间源”：用户要的是自己设备上的自然流逝感，还是业务要求的绝对一致性？这两者在离线、跨时区、后台运行等场景下天然冲突。
