应手动拼接24小时制时间并每次用new Date()实时获取，避免toLocaleTimeString的locale依赖和setInterval的时间漂移：const d=new Date();return${d.getHours().toString().padStart(2,'0')}:${d.getMinutes().toString().padStart(2,'0')}:${d.getSeconds().toString().padStart(2,'0')};
setInterval 每秒更新一次即可，但关键不在“怎么动”，而在“怎么确保始终是24小时制且不闪、不跳、不依赖系统设置”。
toLocaleTimeString 的陷阱：它会随系统变
toLocaleTimeString 默认行为受用户操作系统 locale 控制：美式系统返回 "10:30 AM"，中文系统才返回 "10:30"。你无法靠参数强制统一格式。
- 即使传入
{ hour12: false }，部分旧版 Safari 或 WebView 仍可能忽略该选项 -
toLocaleTimeString('zh-CN', { hour12: false })在 Chrome/Firefox 有效，但在某些安卓 WebView 中 fallback 为 12 小时制 - 不要依赖
Intl.DateTimeFormat的 locale 参数做跨端一致性保障——它只是“建议”，不是“指令”
正确做法是绕过所有 locale 逻辑，手动拼接：
function get24HourTime() {
const d = new Date();
const h = d.getHours().toString().padStart(2, '0');
const m = d.getMinutes().toString().padStart(2, '0');
const s = d.getSeconds().toString().padStart(2, '0');
return `${h}:${m}:${s}`;
}
setInterval 更新节奏与时间漂移问题
用 setInterval(fn, 1000) 看似合理，但存在两个实际问题：
立即学习“前端免费学习笔记（深入）”；
- 函数执行耗时（哪怕几毫秒）会导致下一次触发延迟，长期运行后明显慢于真实时间
- 页面切到后台时，浏览器会节流甚至暂停
setInterval，切回时可能跳秒或连更多秒
推荐方案：用 requestAnimationFrame + 时间差校准，或更简单可靠的做法——每次更新时重新读取 new Date()，不依赖定时器精度：
function updateClock() {
document.getElementById('clock').textContent = get24HourTime();
}
// 首次立即执行，避免白屏等待
updateClock();
// 每 1000ms 触发一次，但每次都是 fresh time
setInterval(updateClock, 1000);- 不要用
setTimeout递归调用并计算下次时间戳——容易累积误差 - 不要试图“对齐整秒”再启动定时器（如
setTimeout(..., 1000 - now.getMilliseconds())），移动端高负载下不可靠
DOM 更新方式影响视觉稳定性
直接写 innerHTML 或 textContent 是最轻量的，但要注意：
- 如果容器内有其他 HTML 结构（比如图标、单位文本），用
textContent更安全，避免 XSS 风险和结构污染 - 不要频繁操作样式属性（如每秒改 color），CSS 动画或 transition 不适合秒级变化
- 若需加闪烁效果（如冒号），用 CSS
::after+animation，而非 JS 切换 class——减少重排
示例 HTML：
<div id="clock" style="font-family: monospace; font-size: 1.5rem;"></div>
无须额外框架，纯原生即可稳定运行。
实际项目中最容易被忽略的是：首次渲染前的时间空白期。用户打开页面瞬间看到空 div，哪怕只有 200ms，体验就断了。务必在 DOMContentLoaded 或脚本加载后立刻调用一次 updateClock()，而不是等 setInterval 第一次触发。
