用 setInterval 每1000ms调用 new Date() 更新页面时间，推荐 toLocaleTimeString() 自适应本地格式；须用 textContent 安全更新 DOM；后台标签页会节流，需 visibilitychange 校准；显示固定时区（如北京时间）应指定 timeZone 或手动修正时差。
用 setInterval 配合 new Date() 实时更新页面时间
浏览器里没法“自动刷新时间”，必须靠 JS 主动读取并重绘。最直接的方式是每秒调用一次 setInterval，在回调里生成新时间字符串，再写入 DOM 元素。
注意别用 setTimeout 递归代替——漏掉一帧就容易漂移；也别设成 500ms 或更短，对低端设备不友好，且人眼根本分辨不出毫秒级变化。
- 推荐间隔设为
1000（单位毫秒），刚好匹配秒级变化 - 时间格式建议用
toLocaleTimeString()，它会按用户系统语言和地区自动适配（比如中文环境输出 “上午11:32:45”，英文环境是 “11:32:45 AM”） - 如果需要固定格式（如 always 24 小时制、补零），改用
getHours()/getMinutes()/getSeconds()手动拼接
把时间塞进指定 <span> 或 <div> 的正确写法
不能直接操作 innerHTML 来更新整个容器，尤其当容器里还有其他子元素或事件监听器时——DOM 重绘会清空绑定的事件、打断焦点、甚至触发意外 reflow。
安全做法是只更新文本节点内容，用 textContent 替代 innerHTML。
立即学习“前端免费学习笔记（深入）”；
- 确保目标元素有唯一标识，比如
id="clock"或class="js-clock" - 获取元素后立即检查是否为
null，避免Cannot set property 'textContent' of null - 示例：
const el = document.getElementById('clock');<br>if (el) el.textContent = new Date().toLocaleTimeString();
页面隐藏或失焦时时间停止跳动？这是浏览器节流导致的
Chrome/Firefox 对后台标签页的 setInterval 会降频（最低约 1s → 1min 一次），所以你切走再回来，发现时间卡了几十秒——不是代码错了，是浏览器故意的。
要保持逻辑准确（比如倒计时、日志时间戳），得改用 requestAnimationFrame + 时间差计算，或者监听 visibilitychange 事件手动校准。
- 简单场景下，可在
setInterval回调里用Date.now()记录上次更新时间，每次计算真实经过秒数，而非依赖定时器精度 - 监听
document.addEventListener('visibilitychange', ...)，页面重新可见时立刻刷新一次时间 - 不要依赖
performance.now()做长期计时，它不包含系统时间偏移，无法替代Date
时区处理：显示本地时间还是服务器时间？
new Date() 默认返回客户端本地时间，和系统设置强绑定。如果你的业务要求统一显示东八区时间（比如后台日志、金融交易时间），就不能直接用 toLocaleTimeString()。
两种常见解法：
- 后端返回带时区的时间戳（如 ISO 格式
"2026-08-26T11:32:45+08:00"），前端用new Date(ISOString)解析，它会自动转成本地等效时间（但显示仍受toLocaleTimeString()影响） - 真正“固定显示北京时间”，需手动加减时差：
const now = new Date();<br>const beijingTime = new Date(now.getTime() + (8 - now.getTimezoneOffset() / 60) * 60 * 60 * 1000);
这行代码把当前时刻强制对齐 UTC+8，再调用toLocaleTimeString('zh-CN', { timeZone: 'Asia/Shanghai' })更稳妥
时区是最容易被忽略的环节——开发时本地测试没问题，上线后海外用户看到的时间完全不对，而且很难复现。
