用setInterval配合new Date()实时更新DOM最快，需将new Date()置于定时器内、用textContent更新、立即执行一次避免空白，并注意时区、内存泄漏和XSS风险。
用 setInterval 配合 new Date() 实时更新页面时间
直接改 DOM 元素的 innerText 或 textContent 最快，不需要框架或库。关键在于别用 setTimeout 递归调用——容易因执行延迟导致跳秒，setInterval 更稳。
常见错误是把 new Date() 写在定时器外，结果只取了一次初始时间；或者用 innerHTML 更新纯文本，有 XSS 风险（哪怕只是时间也建议避开）。
- 把显示时间的元素加上唯一
id，比如<div id="clock"></div> - 在
<script>中立即执行一次更新，避免页面加载后空白一秒 - 用
toLocaleTimeString()自动适配本地格式，比手动拼接getHours()等更省心、更兼容夏令时
const clock = document.getElementById('clock');
function updateClock() {
clock.textContent = new Date().toLocaleTimeString();
}
updateClock(); // 立即显示，不等待第一次 setInterval
setInterval(updateClock, 1000);
需要精确到毫秒？别用 setInterval(…, 1)
浏览器对 setInterval 的最小间隔有限制（通常 ≥4ms），且 JS 单线程 + 事件循环机制下，1ms 不可能稳定触发。真要毫秒级，得靠 requestAnimationFrame + 时间差计算。
但注意：人眼根本分辨不了毫秒跳变，强行做反而增加 CPU 负担，还可能因重排/重绘卡顿导致时间显示“黏住”。大多数场景，“秒级更新 + 毫秒数仅作装饰”就够用。
立即学习“前端免费学习笔记（深入）”；
- 如果只要“看起来”有毫秒（比如
14:22:36.842），可在每次更新时用Date.now() % 1000补零后拼接 - 避免在
setInterval回调里频繁调用getMilliseconds()——它依赖系统时钟精度，不同浏览器返回值可能不同步 - 服务端时间不同步时，用户本地时间再准也没用；需时间敏感场景应考虑 NTP 校准或后端接口对时
Vue/React 项目里别手写 setInterval
框架自有响应式机制和生命周期，手动挂载定时器容易引发内存泄漏：组件卸载了，setInterval 还在跑，回调里访问已销毁的响应式数据会报错（如 Vue 的 Uncaught TypeError: Cannot read property 'xxx' of null）。
Vue 3 Composition API 推荐用 onBeforeUnmount 清理；React 函数组件必须用 useEffect 返回清理函数。漏掉这一步，开发时看不出问题，上线后积累大量无效定时器。
- React 示例中，
useEffect的依赖数组必须为空（[]），否则每次渲染都新建定时器 - 不要在定时器回调里直接
setState({ time: … })——状态更新可能被批量合并，造成视觉延迟；优先用函数式更新或useState的最新值 - SSR 场景下，
setInterval只能在客户端运行，服务端渲染时需加typeof window !== 'undefined'判断
时区处理最容易被忽略的坑
toLocaleTimeString() 默认用用户本地时区，看似合理，但一旦页面含多城市时间对比（如会议倒计时）、或后台日志需统一 UTC，就立刻暴露问题。用 toUTCString() 或 toISOString() 又太难读，得自己格式化。
真正省事的方式是：前端只负责展示，时区转换逻辑交给后端返回 ISO 字符串，前端用 Intl.DateTimeFormat 按需渲染——它支持任意时区，且自动处理夏令时切换。
- 例如显示东京时间：
new Intl.DateTimeFormat('ja-JP', { timeZone: 'Asia/Tokyo' }).format(new Date()) - 避免硬编码偏移量（如
UTC+8），中国标准时间 ≠ 全年 UTC+8（新疆等地实际用东六区时间） - 用户设备系统时区被手动篡改过时，
new Date()仍按系统走，无法检测；业务强依赖准确时区时，需结合 IP 定位或让用户手动选择
动态时间本质是“定期拉取当前系统时间并渲染”，不是魔法。越想绕过浏览器限制去追求绝对精准，越容易掉进时钟漂移、时区混淆、内存泄漏这些静默陷阱里。
