new date() 获取的是用户本地时区时间而非北京时间；需用 gettime() 获取 utc 时间戳并加 8 小时偏移量构造东八区时间，以确保全球用户显示一致的北京时间。
直接用 new Date() 获取的时间不是北京时间，而是用户本地时区时间；必须手动转成东八区（GMT+8），否则海外用户看到的就是错的。
为什么 new Date() 不等于北京时间
浏览器的 Date 对象默认基于用户操作系统设置的时区。比如一个在日本访问页面的用户，new Date().getHours() 返回的是东京时间（GMT+9）；在美国则是 PST 或 EST。中国标准时间（CST）固定为 GMT+8，和系统时区无关——所以不能依赖 toLocaleTimeString('zh-CN') 或类似方法自动“识别”北京时区。
- 常见错误现象：
new Date().toLocaleTimeString()在上海显示正确，在纽约却显示 21:00（比北京时间晚 12 小时） - 根本原因：该方法只是把当前本地时间按指定 locale 格式化，并不切换时区
- 正确思路：拿到本地时间戳（毫秒数），加上 8 小时偏移（
8 * 60 * 60 * 1000），再构造新Date实例
用 getTime() + 时区偏移算出北京时间
这是最轻量、兼容性最好、且不依赖 Intl API 的做法，适合所有现代浏览器和旧版 IE。
- 核心逻辑：先用
new Date().getTime()拿到当前时间戳（UTC 毫秒数），再加8 * 3600 * 1000得到北京时间对应的时间戳 - 注意不要用
getHours() + 8—— 会跨天出错（比如本地是 23:00，+8 后变成 31:00） - 示例代码片段：
function getBeijingTime() {
const utcMs = new Date().getTime();
const beijingMs = utcMs + (8 * 60 * 60 * 1000);
return new Date(beijingMs);
}
<p>const bt = getBeijingTime();
console.log(<code>${bt.getHours()}:${bt.getMinutes()}:${bt.getSeconds()}</code>); // 确保输出北京时间</p>
setInterval 更新时要注意时间跳变
每秒调用一次 setInterval(update, 1000) 看似合理，但实际执行间隔可能因 JS 主线程阻塞而延迟，导致秒数“跳两格”或卡顿一帧。
- 更稳的做法：在每次执行时，计算距离下一个整秒还剩多少毫秒，用
setTimeout精确对齐 - 简单替代方案：用
requestAnimationFrame配合时间差判断，避免视觉跳动 - 性能影响：频繁 DOM 写入（如
innerHTML）比textContent慢，且有 XSS 风险；一律用textContent - 别写成：
setInterval("document.getElementById('clock').innerHTML=...", 1000)—— 字符串形式 eval 是反模式，也难调试
toLocaleTimeString('zh-CN', { timeZone: 'Asia/Shanghai' }) 可以吗
可以，但要注意兼容性。这个 API 在 Chrome 24+/Firefox 29+/Safari 10+ 支持，IE 完全不支持。
- 优点：语义清晰，一行搞定，自动处理夏令时（虽然中国不用）
- 缺点：在老旧环境（如某些政企内网 IE11）会静默失败，返回空字符串或报错
- 稳妥写法是兜底：
try { ...toLocaleTimeString(...) } catch(e) { fallbackToOffsetMethod() } - 注意：
timeZone参数只影响格式化结果，不改变Date对象本身的值
真正容易被忽略的是「首次渲染时机」：页面加载完成前就执行时间函数，getElementById 会返回 null。务必确保 DOM 已就绪，或者把脚本放在
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
