datetime属性必须存在且严格符合ISO 8601格式，否则解析器静默忽略；仅允许五类合法值，动态生成需规避手拼、toLocaleString等陷阱，显示文本与datetime值必须解耦。
datetime属性必须存在且格式合法，否则机器直接忽略
不加 datetime 属性的 <time> 标签，对搜索引擎、屏幕阅读器、结构化数据提取器来说和普通 <span> 没区别。浏览器不会报错，但所有解析器都静默跳过——不是“识别失败”，而是“根本没读”。验证方法很简单：打开 DevTools → 选中元素 → 看 DOM 中 datetime 属性是否存在、值是否为非空字符串（灰色 “undefined” 或空值即失效）。
ISO 8601 格式错一个字符就解析失败
机器只认标准，不接受“看起来像”。常见非法写法包括：
-
2026/09/21（斜杠分隔，非 ISO） -
2026-9-21（月份/日期缺前导零） -
2026-09-21 14:11（缺T分隔符） -
2026-09-21T14:11+08（时区偏移缺冒号） -
2026-09-21T14:11:00 CST（用缩写而非+08:00或Z）
正确写法只认这五类（W3C 明确限定）：
-
2026-09-21（仅日期，隐含当日 00:00:00 UTC） -
2026-09-21T14:11:00+08:00（推荐：带时区偏移） -
2026-09-21T06:11:00Z（UTC 时间，结尾必须大写Z） -
14:11（仅时间，仅限上下文已知日期，如课表） -
PT1H30M（持续时间，非时间点）
后端模板或 JS 动态生成 datetime 的三个高危陷阱
动态生成最容易翻车，因为人类可读 ≠ 机器可读：
立即学习“前端免费学习笔记（深入）”；
- ❌ 直接用
toLocaleDateString()或toString()：输出类似"2026/9/21 上午2:11:00"，完全非法 - ❌ 手拼字符串：
date.getFullYear() + '-' + (date.getMonth()+1)必然漏补零，且不处理时区、夏令时 - ❌ 用
toISOString().slice(0, 19)得到 UTC 时间却硬套本地语义（比如页面标“北京时间14:11”，却填2026-09-21T06:11:00）
稳妥做法：
- 要 UTC：用
new Date().toISOString()，保留Z（如"2026-09-21T06:11:00.123Z"），截断毫秒即可 - 要本地时区偏移（如 +08:00）：别手算，用
Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Shanghai', hour12: false }).formatToParts()构造，或依赖后端统一输出 - 服务端渲染优先：HTML 初始加载时
datetime就得是合法字符串，JS 后续改它对爬虫无效
显示文本和 datetime 值必须解耦，这是最常卡住的设计点
人眼看到的内容可以自由本地化、模糊化、动态化；datetime 值必须静态、精确、不可变。二者不是“同步更新”的关系：
- ✅ 允许：
<time datetime="2026-09-21T14:11:00+08:00">刚刚</time> - ✅ 允许：
<time datetime="2026-09-21T14:11:00+08:00">发布会当天</time> - ❌ 禁止：每次刷新把
datetime改成"2026-09-21T14:11:05+08:00"，原始时间点就丢了 - ❌ 禁止：用
aria-label或<span>替代<time>，Google Rich Results Test 和屏幕阅读器都不认
真正容易被忽略的是：一旦你决定用 <time>，就必须把它当成一个“时间身份证”来维护——它不是装饰，是契约。写错格式、动态篡改、或和文本强绑定，都会让这个契约失效。
