最稳方案是每次用 new date() 获取真实时间而非计数器推算；需补零、处理12小时制、月份+1、星期查表；纯文本用 textcontent；初始化先调用再定时；脚本放 body 底部或等 domcontentloaded。
直接用 setInterval 每秒调用一次 new Date() 并更新 DOM，是最简单可行的方案；但要注意 DOM 更新时机、格式补零、初始渲染和时区行为——这些地方一不留神就显示错乱或卡顿。
为什么 setInterval(updateTime, 1000) 有时会跳秒或不准
浏览器主线程繁忙时，setInterval 的回调可能延迟执行，导致连续两帧都更新同一秒，或跳过一秒。这不是代码写错了，而是定时器机制本身的限制。
- 实际触发时间取决于 JS 主线程空闲程度，不是严格每 1000ms 执行一次
- 如果
updateTime函数里做了耗时操作（比如重排、大量 DOM 查询），会进一步加剧偏差 - 更稳的做法是每次执行时用
new Date()获取真实当前时间，而不是靠计数器推算 - 示例中应避免写成
seconds++这类自增逻辑，必须每次都读系统时间
toLocaleTimeString() 和手动拼接字符串的区别
toLocaleTimeString() 自动适配用户本地时区和语言习惯，但不可控细节多；手动拼接（如 getHours() + padStart(2, '0')）能精确控制格式，也更容易加 AM/PM 或中文星期。
-
toLocaleTimeString('zh-CN')可能输出 “下午12:38:26”，但无法单独去掉“下午”只留12小时制数字 - 手动提取
getHours()后需自行处理 12 小时制：若hour === 0→ 显示 12，若hour > 12→hour - 12，再判断 AM/PM - 月份和星期要 +1 和查表：`['星期日','星期一',...][date.getDay()]`，
getMonth()返回 0–11，不加 1 会显示“1月”变“0月” - 所有数字字段（月、日、时、分、秒）都建议用
String(x).padStart(2, '0')补零，避免出现 “2026-8-26 12:8:5” 这种格式错误
textContent vs innerHTML 写入时间文本
纯时间内容一律用 textContent，不用 innerHTML —— 既防 XSS，又快。
-
innerHTML会触发 HTML 解析、DOM 构建、样式计算全流程，哪怕你只写个"12:38:26" -
textContent是纯文本赋值，跳过解析环节，性能更好，且杜绝意外执行脚本的风险 - 只有当你需要在时间里嵌入
<span class="ampm">PM</span>这类带标签的结构时，才考虑innerHTML，但此时务必对内容做转义 - 初始化时也别留空元素，例如
<div id="clock"></div>，最好给个占位文字：<div id="clock">加载中...</div>
确保页面加载完成再启动定时器
脚本放在 底部最省事；如果必须放 ，就得等 DOM 就绪，否则 document.getElementById 找不到元素。
- 错误写法：
<script>setInterval(updateTime, 1000)</script>放在里，updateTime里查不到 DOM 元素，报错且不运行 - 推荐写法：用
DOMContentLoaded事件包裹，或把 script 标签移到前 - 首次显示别依赖定时器：先手动调一次
updateTime()，再setInterval，避免页面打开后空白 1 秒 - 移动端注意：部分 iOS Safari 在后台标签页会暂停
setInterval，切回前台才恢复，这是浏览器策略，无法绕过
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
