datetime 属性失效的根本原因是格式非法而非语义误用，必须严格使用补零的 ISO 8601 字符串（如“2026-06-10T12:48:00+08:00”），缺 T、漏冒号、用斜杠或缩写时区均导致识别失败。
datetime 属性必须是字面量级的 ISO 8601 字符串，错一个字符（比如漏 T、用 / 代替 -、月份没补零）就失效——浏览器不会报错，但 document.querySelector('time').dateTime 返回空字符串，Google Rich Results Test 直接标 “Missing datePublished”。
datetime 值为什么总被忽略？
常见现象不是“不生效”，而是“压根没被识别”。根本原因几乎全是格式非法，而非语义误用。
- 写成
"2026/06/10"或"2026-6-10"：年月日必须全为数字且补零，2026-06-10才合法 - 写成
"2026-06-10 12:48"：缺T分隔符，必须是"2026-06-10T12:48" - 写成
"2026-06-10T12:48+08"：时区偏移必须是+08:00，不能省略冒号 - 写成
"2026-06-10T12:48:00 CST"：CST是非标准缩写，只接受Z或±HH:MM
验证方式很简单：打开 DevTools → 选中 <time> 元素 → 看 DOM 中 datetime 属性是否存在，值是否为上述任一合法格式。若属性名显示为小写 datetime 但值为空或非法，就等于没写。
前端 JS 动态生成 datetime 的安全写法
别用 toLocaleString()、toString()、手拼字符串——它们输出不可靠，且极易漏掉前导零或混淆时区。
立即学习“前端免费学习笔记（深入）”；
- 要 UTC 时间：直接用
new Date().toISOString()，返回类似"2026-06-10T04:48:00.123Z"，可截断秒后三位并保留Z - 要本地时间带偏移（如北京时间）：不要手动加
+08:00，而应先获取时区偏移（new Date().getTimezoneOffset()），再构造字符串；更稳的是用Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Shanghai', hour12: false }).formatToParts()配合formatISO类库 - 绝对避免：
date.getFullYear() + '-' + (date.getMonth()+1) + '...'—— 月份/日期不补零、夏令时翻车、时区逻辑全崩
dateTime 属性返回的是原始字符串，不是 Date 对象。想转成 JS 时间？必须显式调用 new Date(el.dateTime)，且注意 Safari 对无秒数格式（如 "2026-06-10T12:48"）支持不稳定。
什么时候不该用 <time> 标签？
它不是“所有带时间字样的内容都该套一层”的装饰标签，而是语义开关：开了就得提供机器可验证的绝对时间点或明确时长。
- 营业时间：
"9:00–18:00"没绑定具体日期，无法解析为唯一时间点，用<span>更合适 - 相对时间：
"刚刚"、"2小时后"、"下周三"——datetime无法表达模糊值，硬填会污染语义 - 年份范围：
"2020–2024"必须拆成两个<time>分别标起止，或放弃语义化 - 纯版本号、编号、价格：
v2.3.1、#123、¥99—— 完全无关，滥用反而干扰屏幕阅读器
真正难的不是格式怎么写，而是判断“这个时间值是否值得暴露给机器”。很多页面把“更新于：刚刚”硬套 <time>，结果 datetime 只能填个静态时间或留空，结构化数据提取器一看就跳过。
显示文本和 datetime 值可以不同，但必须逻辑自洽
<time> 的核心价值是分离人类可读文案与机器可读时间。你可以自由控制显示内容，只要 datetime 值准确、无歧义。
- 合法：
<time datetime="2026-06-10T12:48:00+08:00">刚刚</time>（配合 JS 实时更新textContent） - 也合法：
<time datetime="2026-06-10T12:48:00+08:00">今天中午</time>（前提是页面生成于当天） - 错误：
<time datetime="2026-06-10">距今还有 3 天</time>—— 静态datetime和动态语义文本矛盾，机器无法验证
容易被忽略的一点：没有 datetime 属性的 <time> 标签，对搜索引擎、屏幕阅读器、RSS 抓取器来说，和普通 <span> 没区别。它只是一层视觉容器，不是语义化工具。
