Date 获取的是用户设备本地时间，非服务器时间；需用 getFullYear()、getMonth()+1 等标准方法；整秒更新推荐 setTimeout 动态对齐；格式化优先用 Intl.DateTimeFormat 支持国际化。
用 Date 获取本地时间，不是服务器时间
浏览器里显示的时间永远是用户设备的本地时间，Date 构造函数默认读取的就是这个。别指望它自动同步 NTP 或服务端时间——除非你主动发请求拉取，否则它和你电脑右下角那个时间完全一致。
常见错误现象：new Date().getHours() 在凌晨显示 0 点，但用户以为是“昨天”，其实是本地时区没理解清楚；或者误用已废弃的 getYear()，返回 126 而不是 2026。
- 始终用
getFullYear()、getMonth() + 1、getDate()这类标准方法 - 月份从 0 开始，
getMonth()返回 7 表示八月（当前是 8 月，所以返回值是 7） - 星期几用
getDay()，返回 0–6，0 是星期日，3 是星期三（今天就是 3）
每秒更新不能只靠 setInterval(updateTime, 1000)
setInterval 看似简单，但实际执行间隔不精确：JS 主线程繁忙时会延迟，甚至出现跳秒（比如 10:46:02 → 10:46:04）。更稳的方式是每次更新时重新计算与当前毫秒的差值，再动态调整下次触发时机。
性能影响：如果页面有大量定时器或重绘操作，setInterval 容易堆积未执行任务，尤其在标签页切走又切回时。
立即学习“前端免费学习笔记（深入）”；
- 推荐写法：
setTimeout(updateTime, 1000 - (Date.now() % 1000))，让下一次调用尽量对齐整秒 - 更新前先清除旧定时器（尤其在单页应用中反复挂载/卸载时），避免内存泄漏
- 如果只是展示年份或日期（不需秒级刷新），用
setTimeout更新一次就够了，别浪费资源
格式化输出别拼字符串，优先用 Intl.DateTimeFormat
手写 padStart(2, '0') 和数组映射星期/月份虽然能跑通，但一碰到国际化就崩：中文要“八月”，英文要“August”，阿拉伯语还要 RTL 排版。硬编码格式很快变成维护噩梦。
兼容性注意：IE 不支持 Intl.DateTimeFormat，但现代项目基本可忽略；如需兼容，可用 date-fns 或 dayjs 的 format 方法替代，但纯原生方案里它是首选。
- 显示“2026年8月26日 星期三 10:46”：
new Intl.DateTimeFormat('zh-CN', { dateStyle: 'full', timeStyle: 'short' }).format(new Date()) - 只取小时分钟（如做倒计时）：
{ hour: '2-digit', minute: '2-digit' } - 多时区场景必须加
timeZone选项，例如{ timeZone: 'Asia/Shanghai' }，否则仍按本地时区算
DOM 插入要防空节点和重复绑定
最常踩的坑是脚本执行时目标元素还没加载出来，或者同一个脚本被多次引入导致多个 setInterval 同时跑。
错误现象：document.getElementById('clock') 返回 null，后续报错；或者时间一秒跳两次。
- 确保 JS 在 DOM 尾部执行，或用
DOMContentLoaded包裹初始化逻辑 - 给定时器 ID 加变量缓存（如
let timerId），更新前先clearTimeout(timerId) - HTML 中只放一个带 id 的容器：
<div id="clock"></div>，别用 class 或多个同名 id
真正难的不是让时间动起来，而是让它动得准、动得省、动得不翻车——尤其是跨时区、跨语言、跨页面生命周期的时候。本地时间看似简单，实则处处是隐式依赖。
