动态显示时间必须用 setInterval(updateClock, 1000) 定时刷新，避免只执行一次导致冻结；需缓存 DOM 元素、用 textContent 更新、手动格式化确保精度与安全，且依赖客户端时间存在偏差风险。
直接用 new Date() 获取时间再塞进页面，但只执行一次就停了——这是最常见失效原因。动态显示必须配合定时刷新，否则页面加载完时间就冻结了。
为什么 setInterval(updateClock, 1000) 是底线频率
每秒更新一次是平衡精度与性能的合理选择。高频（如 100ms）会导致无意义重绘、CPU 占用上升，且人眼无法分辨毫秒级变化；过低（如 5 秒）则明显“卡顿”。setInterval 比递归 setTimeout 更稳，后者可能因 JS 执行延迟累积跳秒。
- 别写
setInterval("document.getElementById('clock').textContent = new Date().toLocaleTimeString();", 1000)—— 字符串形式调用已过时，且无法捕获错误 - 避免在定时器回调里反复查 DOM：
document.getElementById('clock')应提前缓存为变量 - 如果页面有多个时钟，每个都应独立缓存自己的元素引用，不要共用一个
querySelector结果
toLocaleTimeString('zh-CN') 和手动拼接怎么选
toLocaleTimeString('zh-CN') 能输出 “13:07:22” 这类本地化格式，但不保证带年月日，也不控制补零逻辑；手动拼接（如 getFullYear() + padStart(2, '0')）才能稳定输出 “2026-08-26 13:07:22”。
- 中文 Windows/macOS 下，
toLocaleString()可能输出 “2026/8/26 下午1:07:22”，字段顺序和分隔符不可控 - 需要精确格式（比如日志样式或 API 时间戳）时，必须手动取值 + 补零：
String(date.getDate()).padStart(2, '0') - 时区默认是客户端本地时区，若需服务端时间，得走 AJAX 或预埋时间戳，不能靠前端
Date对象“校准”
textContent vs innerHTML vs innerText 的坑
更新时间文本时，textContent 是唯一推荐方式。它只替换文字内容，不解析 HTML，也不会受 CSS 隐藏影响，更安全、更快。
立即学习“前端免费学习笔记（深入）”；
- 别用
innerHTML = timeStr：万一timeStr里混入<script>或标签字符，会触发意外解析甚至 XSS - 别用
innerText：当目标元素被display: none或父级隐藏时，赋值可能失败或行为不一致 - 绝对不要用
document.write()：页面加载完成后调用会清空整个 DOM，彻底毁掉页面
真正容易被忽略的是：所有时间操作都依赖客户端系统时间。用户若手动改过系统时钟，页面显示就会错，且无法自动纠正——这不是代码问题，而是设计前提。需要强一致性的时间展示，必须引入服务端时间源并做差值补偿。
