<time>标签本身不自动更新时间，需JavaScript每秒修改textContent和datetime属性；datetime必须为ISO 8601格式，否则语义失效；多时区需用class或data属性区分；SSR页面存在时间闪烁问题。
只写 HTML 标签（比如 <time>）无法让时间“动起来”——它天生是静态语义容器，不是时钟。 真正起作用的是 JavaScript，而 <time> 的价值在于：让机器（搜索引擎、读屏软件）知道“这串文字代表一个时间点”，前提是你要用 JS 主动更新它的 textContent 和 datetime 属性。
为什么 <time datetime="2024-05-20">今天</time> 不会跳秒
<time> 标签本身不触发任何更新逻辑。浏览器只把它当普通 HTML 元素渲染一次，之后就不管了。你看到的“今天”只是纯文本，datetime 属性哪怕写成中文（如 "2024年5月20日"），也完全失效——它必须是 ISO 8601 格式（如 "2024-05-20T14:30:00Z"），否则结构化数据和辅助技术根本识别不了。
常见错误现象：
- 页面加载后时间卡死，不再变化
- 读屏软件朗读出错（比如把“下午三点”读成“2024年5月20日”）
- Google 搜索结果里富媒体卡片显示的是服务端时间，而非用户当前时间
用 setInterval 每秒更新 textContent 是最稳方案
对大多数页面来说，setInterval(updateClock, 1000) 足够可靠，且比 requestAnimationFrame 更易理解、更少兼容性问题。关键是要避免直接操作 innerHTML——它会触发 HTML 解析，有 XSS 风险，也更慢。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
实操建议：
- 用
document.querySelector('time')或带 class 的选择器（如document.querySelector('.live-time')）定位目标元素 - 更新时优先用
.textContent，不是.innerText或.innerHTML - 每次更新都同步设置
datetime属性：$time.setAttribute('datetime', now.toISOString()) - 初始调用一次
updateClock()，避免页面刚打开时空白
多个时间区域或格式需求，别硬套一个 querySelector('time')
如果页面要同时显示“北京时间”“纽约时间”“服务器时间”，靠全局 querySelector('time') 会全部刷成同一个值。必须用唯一标识区分：
- 加
class：<time class="beijing-time"></time>+document.querySelector('.beijing-time') - 或用
data-zone属性：<time data-zone="ny"></time>+document.querySelector('time[data-zone="ny"]') - 格式差异大时（比如一个要年月日时分秒，另一个只要时分），建议封装成独立函数，而不是堆 if/else
SSR 页面首次加载会“闪一下”
Next.js、Nuxt 这类框架在服务端渲染时，<time> 初始值只能是服务器时间（比如 UTC+0），等客户端 JS 加载执行后，才替换成用户本地时间（比如 UTC+8）。这个从“08:00:00”跳到“16:00:00”的过程肉眼可见。
缓解方法有限，但得知道：
- 不能靠 JS 延迟渲染来避免——那会牺牲首屏体验
- 可考虑服务端注入一个
data-timestamp属性，JS 启动时基于它做平滑过渡（比如补秒），但复杂度陡增 - 若只是装饰性时钟（比如页脚右下角），其实不用
<time>，用<span>更轻量，也省去语义维护负担
真正容易被忽略的，是 datetime 属性和显示文本之间的语义一致性——它不是可选动作，而是用了 <time> 就必须承担的责任。
