最稳妥做法是用 setInterval 每1000毫秒统一更新所有 time-cell 单元格，先清除旧定时器、避免重复启动，并用服务端时间校准关键场景。
用 setInterval 每秒更新表格单元格内容
直接在 <td> 里写 new Date().toLocaleTimeString() 不会自动刷新——HTML 是静态的，JS 需主动驱动更新。最稳妥的做法是用 setInterval 定期重写单元格文本内容。
常见错误是把时间获取逻辑写在循环外（比如只执行一次），或误用 setTimeout 而没递归调用，导致只更新一次。
- 选一个明确的
<td id="clock">或class="time-cell"作为目标容器 - 初始化时先填一次，避免页面加载后空白 1 秒
- 间隔设为
1000（毫秒），别用60000（分钟级）——秒针不动会显得“卡住” - 用
toLocaleTimeString()而非toTimeString()，前者尊重用户系统时区和格式设置
避免重复启动定时器导致时间跳变
如果页面有局部刷新、组件重载或脚本被多次引入，setInterval 可能被反复调用，结果是多个定时器同时运行，单元格内容一秒内刷好几次，甚至出现时间倒退或乱序。
解决方法不是靠“加个 flag 判断”，而是用可清除的引用 + 显式清理逻辑：
立即学习“前端免费学习笔记（深入）”；
- 把
setInterval返回值存到变量（如let clockTimer） - 每次重新启动前先
clearInterval(clockTimer) - 若用在 SPA 路由切换场景，务必在组件卸载/离开前调用
clearInterval - 不推荐用
document.getElementById('clock').textContent = new Date().toLocaleTimeString()直接写死——它没绑定上下文，后续维护难
兼容性与性能：别在每个单元格都跑独立定时器
一个表格若有 10 个时间单元格，有人会为每个写一套 setInterval，这不仅浪费资源，还会因微小延迟造成各单元格秒数不同步（比如差 10–30ms）。
真实项目中应统一调度：
- 只启一个全局定时器，用
document.querySelectorAll('.time-cell')批量更新所有匹配单元格 - IE11 不支持
textContent在某些 SVG 场景下，稳妥起见可用innerText替代（但注意它会触发重排） - 移动端 WebView（尤其旧版 Android）对
setInterval的精度不保证，若需高一致性，可改用requestAnimationFrame+ 时间差校准，但绝大多数业务场景没必要 - 别用
innerHTML更新纯文本内容——存在 XSS 风险且性能更低
服务端时间 vs 客户端时间：你真需要“当前时间”吗？
用户本地时间可能被手动调快/调慢几小时，甚至开启飞行模式导致系统时间停滞。如果表格用于日志时间戳、订单创建时间等关键场景，new Date() 不可靠。
这时该考虑服务端对齐：
- 首次加载时从 API 获取服务器当前时间（如
/api/time返回 ISO 字符串），再用它作基准，客户端仅做偏移补偿 - 避免每秒都发请求——可在页面初始化时拉一次，然后靠
setInterval本地推算，每 5 分钟再同步一次修正漂移 - 若用 WebSocket，可让服务端主动推送时间校准事件，但复杂度陡增，小项目不必强求
多数内部管理页用客户端时间就够了，但上线前得确认业务方是否接受误差 ±2 分钟。
