用JavaScript Date+setInterval可实现前端时钟，但需将脚本移至</body>前或加defer属性防getElementById返回null；用textContent更新更安全；setInterval易偏差，应手动首调并考虑setTimeout动态校准；toLocaleTimeString须指定locale和选项避免格式混乱。
直接用 JavaScript 的 Date 对象配合 setInterval 就能稳定实现，不需要框架、不依赖服务端，但必须注意执行时机和 DOM 更新方式，否则页面一加载就报错或时间卡死不动。
为什么 document.getElementById 会返回 null
脚本在 HTML 元素解析完成前就执行了，最常见于把 <script> 放在 <head> 里且没加 defer。浏览器按顺序解析，<head> 里的脚本先跑，但此时 <div id="clock"> 还没出现。
- 把
<script>移到</body>前是最简单可靠的解法 - 或者保留
<head>中的脚本，但加上defer属性：<script defer src="clock.js"></script> - 不推荐用
window.onload或DOMContentLoaded包一层——多一层异步嵌套，反而容易漏掉错误处理
textContent vs innerHTML 更新时间文本
纯时间字符串（如 "12:21:05"）用 textContent 更安全、更快。用 innerHTML 不仅没好处，还可能因意外插入 HTML 字符导致 XSS（虽然时间本身不会含标签，但养成习惯很重要）。
- 正确写法：
document.getElementById('clock').textContent = formattedTime; - 错误写法：
document.getElementById('clock').innerHTML = formattedTime;（除非你明确要渲染带样式的 HTML 片段） - 如果后续要加秒数动画（比如数字翻转效果），仍应优先操作
textContent，再用 CSS 控制视觉表现
setInterval 每秒更新的三个实际问题
setInterval(updateTime, 1000) 看似合理，但在真实场景中容易出偏差：用户切到其他标签页时，Chrome 会节流定时器；函数执行耗时略超 1000ms 会导致跳秒；初始时间可能比整秒晚几十毫秒。
立即学习“前端免费学习笔记（深入）”；
- 首次调用
updateTime()必须手动触发一次，避免页面打开后空白 1 秒才显示 - 不要用
setInterval(() => { ... }, 1000)匿名函数，不利于调试和清除（比如页面卸载时需clearInterval） - 如果要求“严格对齐秒级”，得用
setTimeout动态计算下次触发时间，而不是固定间隔——但绝大多数展示场景不需要这么精确
toLocaleTimeString() 的区域与格式陷阱
不传参数的 toLocaleTimeString() 行为不可控：中文系统可能输出 "下午12:21:05"，英文系统可能是 "12:21:05 PM"，甚至某些浏览器返回 12 小时制却没 AM/PM 标识。
- 明确指定语言和选项：
now.toLocaleTimeString('zh-CN', { hour12: false, hour: '2-digit', minute: '2-digit', second: '2-digit' }) - 避免用
toLocalString()一次性输出日期+时间——它包含空格、逗号等不可预测分隔符，不利于 CSS 对齐或后续解析 - 如果需要 ISO 格式（如
"2026-08-26 12:21:05"），别拼字符串，改用toISOString().slice(0, 19).replace('T', ' ')，但注意这是 UTC 时间，不是本地时间
真正难的不是写对一行 new Date()，而是让时间在各种浏览器、后台标签页、慢速设备上都保持可读、不报错、不跳变——这些细节藏在执行顺序、API 选项和 DOM 更新方式里，而不是语法本身。
