time标签必须添加合法iso 8601格式的datetime属性，否则语义失效；datetime需静态、带时区（如+08:00或z），不可用斜杠、单数字月份/日期、空格分隔或非标准时区写法，且文本内容与datetime完全解耦。
time 标签不加 datetime 就等于没写
浏览器、搜索引擎、屏幕阅读器根本不会把 <time>昨天</time> 当成时间——它和 <span>昨天</span> 没区别。机器识别的唯一入口就是 datetime 属性，缺了它，整个语义化就断了。
常见错误现象：
-
<time>2026/06/17</time>—— 斜杠分隔符非法，ISO 8601 只认短横线 -
<time datetime="2026-06-17 18:54">现在</time>—— 缺T分隔符，new Date("2026-06-17 18:54")会返回Invalid Date -
<time datetime="2026-6-17">今天</time>—— 月份/日期必须两位补零，2026-6-17不是合法 ISO 字符串
datetime 值必须是静态、合法、初始加载即存在的 ISO 字符串
不能靠 JS 在 DOM 加载后再往 datetime 里塞值。Google Search Console、结构化数据提取器只看 HTML 初始源码，动态插入的 datetime 直接被忽略。
后端或模板渲染时要注意：
- 别用
toLocaleDateString()或format("YYYY/MM/DD")拼接 —— 输出格式不可控，且非标准 - Node.js 模板中优先用
toISOString().slice(0, 10)（仅日期）或toISOString().replace("Z", "+00:00")（UTC 时间） - 若需本地时区（如 +08:00），必须显式计算偏移并拼接，例如：
new Date().toLocaleString("sv-SE", { timeZone: "Asia/Shanghai" }).replace(" ", "T") + "+08:00"，但更稳妥的是用Intl.DateTimeFormat的formatToParts()构造 - 绝对不要写
datetime="next Monday"或datetime="soon"—— 这些不是有效值，解析器直接跳过
显示文本和 datetime 完全解耦，这是设计本意
你完全可以把 datetime 写死为精确时间戳，而标签内文本写“刚刚”“还剩 2 小时”“发布会当天”。二者职责分离：机器读 datetime，人看文本。
典型使用场景：
- 博客页：
<time datetime="2026-06-05T14:22:00+08:00">3天前</time> - 倒计时页：
<time datetime="2026-06-20T20:00:00+08:00">距直播开始还有 3 天</time>（配合 JS 定时更新 textContent） - 多语言站点：
<time datetime="2026-06-17">Jun 17, 2026</time>（en-US）和<time datetime="2026-06-17">2026年6月17日</time>（zh-CN）共用同一datetime
关键陷阱：JS 更新文本时，千万别顺手把新字符串也赋给 datetime，否则原始时间点就永久丢失了。
带时区的 datetime 是硬性要求，不是可选项
写 datetime="2026-06-17T18:54:00"（无时区）看似能过校验，但 JS 解析结果依赖用户设备时区，搜索引擎也可能按 UTC 处理，导致发布时间错乱。
推荐写法（按场景选）：
- 明确本地时间（如中国用户）：
2026-06-17T18:54:00+08:00 - 服务端统一用 UTC：
2026-06-17T10:54:00Z（注意是大写Z，不是小写z） - 禁止写：
2026-06-17T18:54:00GMT+8、2026-06-17T18:54:00 CST、2026-06-17T18:54:00 UTC+8—— 这些都不是 ISO 8601 合法时区表示
真正容易被忽略的点：哪怕页面只面向单一地区，只要内容可能被全球爬虫抓取、或未来要接入国际化系统，就必须在 datetime 中显式声明时区。模糊等于无效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
