toLocaleTimeString() 是浏览器原生最快方式，复用系统 ICU 库，自动适配本地格式，配合 setInterval 每秒更新 textContent，避免重复创建 Date 对象和 HTML 解析开销。
直接用 toLocaleTimeString() + setInterval 最快
不需要手动拼年月日、不用判断 AM/PM、不涉及时区转换——只要纯文本实时刷新时分秒，toLocaleTimeString() 是浏览器原生最快的方式。它复用系统 ICU 库，比手拼字符串快 2–3 倍，且自动适配用户本地格式（如中文环境输出“11:38:25”，英文环境可能是“11:38:25 AM”）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把
<div id="clock"></div>放在<body>底部，避免阻塞渲染 - 脚本里只调一次
new Date()，然后每秒更新 DOM，别在setInterval回调里反复 new 对象（虽影响小，但没必要） - 用
textContent而非innerHTML，避免 HTML 解析开销和潜在 XSS 风险
<div id="clock">加载中</div>
<script>
function update() {
document.getElementById("clock").textContent = new Date().toLocaleTimeString();
}
update(); // 立即显示，不等第一秒
setInterval(update, 1000);
</script>
想省掉 setInterval？用 requestAnimationFrame 更准但未必更快
它不是“更快”，而是“更准”：在页面可见且重绘时才触发，不会因 JS 主线程卡顿而跳秒。但对普通时间显示来说，setInterval 的 1000ms 误差（通常 ±5ms）完全够用；而 requestAnimationFrame 每帧都调用（60fps 下每 16ms 一次），若不做秒级节流，反而增加 CPU 开销。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 仅当你要做高精度倒计时、或页面有大量动画时才考虑它
- 必须加秒数判断，否则每帧都写 DOM，性能反降：
if (now.getSeconds() !== lastSec) { ...; lastSec = now.getSeconds(); } - 记得监听
visibilitychange，页面切到后台时暂停，防止无意义轮询
为什么别用 toISOString() 或手拼格式？
toISOString() 返回的是 UTC 时间（如 "2026-08-26T03:38:25.123Z"），要转成本地时间得先调 toJSON() 再手动加时区偏移，代码变长、易出错；手拼格式（getFullYear() + padStart()）虽然可控，但多 5–6 行代码、多 3–4 次方法调用，首次渲染延迟略高，且补零逻辑容易漏（比如忘了 getMonth() + 1）。
常见错误现象：
- 页面刚打开时显示 “Invalid Date” → 忘了在
setInterval外先调一次初始化函数 - 时间卡在某秒不动 → 把
setInterval写在DOMContentLoaded里，但元素还没挂载（ID 写错或 script 放太早） - 中文 Windows 用户看到 “8/26/2026, 11:38:25 AM” → 没传 locale 参数，改用
toLocaleTimeString("zh-CN", { hour12: false })即可
真正影响“快”的其实是 DOM 更新位置
再快的 JS 时间计算，如果目标元素是 <table> 里深层嵌套的 <td>，或者父容器用了 transform 或 will-change，重排重绘成本会远超时间计算本身。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给时间容器加
id，用getElementById（最快查找方式） - 避免把它塞进
contenteditable区域或 Shadow DOM 深层（需额外穿透逻辑） - 如果页面已用框架（Vue/React），别硬插原生 JS —— 框架响应式更新本身就有开销，此时原生反而更慢
最简可行代码就三行 JS，其余全是 HTML 容器。快的关键不在“炫技”，而在避开 DOM 查找、格式转换、重绘陷阱这些真实瓶颈。
