用 JavaScript Date 实现时间显示需注意执行时机、DOM 操作、时区及首屏一致性；document.getElementById 返回 null 主因是脚本执行早于 DOM 解析；setInterval 易受主线程阻塞影响导致跳秒，推荐 requestAnimationFrame + 时间差判断；纯文本用 textContent 更安全高效；toLocaleTimeString() 比手拼更可靠，但需明确时区策略。
直接用 JavaScript 的 Date 对象配合定时更新就能实现，不需要框架或服务端参与；但写错执行时机、滥用 innerHTML 或忽略时区差异，会导致时间不准、XSS 风险或页面白屏。
为什么 document.getElementById 会返回 null
脚本在 DOM 元素解析前就执行了，最常见于 <script></script> 放在 里且没加 defer 属性。
- 把
<script></script>移到前是最简单可靠的解法 - 或者用
document.addEventListener('DOMContentLoaded', ...)包裹初始化逻辑 - 检查目标元素是否真有对应
id，比如写成time-display却查clock - 别在控制台直接敲
document.getElementById('xxx').textContent = ...—— 页面可能还没加载完
setInterval(updateTime, 1000) 为什么秒数会跳变或卡顿
setInterval 只保证“大约每秒执行一次”，主线程阻塞（如长任务、大量 DOM 操作）会让回调延迟累积，导致秒数显示滞后甚至连跳两秒。
- 改用
requestAnimationFrame+ 时间差判断：只在真实秒数变化时才更新 DOM - 避免在
updateTime里做耗时操作，比如反复调用getElementsByClassName或拼接大字符串 - 不要用
setInterval更新毫秒级时间（如HH:MM:SS:mmm），浏览器重绘频率撑不住 - 如果页面标签页被切走，
setInterval在部分浏览器中会降频甚至暂停，需监听visibilitychange事件手动恢复
textContent 和 innerHTML 哪个该用
只要显示纯时间字符串（如 "11:04:22"），一律用 textContent —— 安全、快、无 HTML 解析开销。
立即学习“前端免费学习笔记（深入）”；
-
innerHTML会触发 HTML 解析，哪怕内容只是数字，也存在潜在 XSS 风险（比如用户可控输入混入） -
textContent设置速度比innerHTML快约 20%~30%，尤其在低端设备上感知明显 - 只有当你需要嵌入
<span class="second">22</span>这类带样式的时间片段时，才考虑innerHTML，但此时应严格校验/转义内容 - 别用
innerText：它受 CSS 影响（如display: none元素内容不计入），行为不一致
toLocaleTimeString() 和手拼字符串哪个更可靠
优先用 toLocaleTimeString()，特别是要支持多语言或自动适配本地习惯（如中文用“上午/下午”，德语用“Uhr”）。
- 手拼字符串容易漏补零：
getHours()返回9，不padStart(2, '0')就变成"9:4:22" -
toLocaleTimeString('zh-CN', { hour12: false })自动处理 24 小时制、千位分隔、空格等细节 - 但注意：它依赖用户操作系统设置，若需强制 UTC 时间，得用
toISOString()再手动截取和转换 - 服务端渲染（SSR）页面中，首次 HTML 是静态生成的，JS 加载后才动态更新 —— 这会导致首屏时间与用户当前时间不一致，无法靠前端完全规避
真正容易被忽略的是时区和首屏体验：用户看到的“当前时间”到底是他本地的、服务器的、还是某个固定时区的？这个选择必须在写第一行 JS 前就明确，而不是等 new Date() 输出了奇怪结果再回头改。
