time标签仅当datetime属性为合法ISO 8601字符串时才具语义价值，否则等同span；常见错误包括斜杠分隔、缺零、缺T分隔符、时区格式错误等，必须严格校验。
time 标签只有带合法 datetime 属性时才真正起作用，否则它和 span 没区别——搜索引擎、屏幕阅读器、结构化数据工具全都不认。
datetime 属性必须是 ISO 8601 字符串，错一个字符就失效
浏览器不报错，但 document.querySelector('time').dateTime 会返回空字符串，Google Rich Results Test 直接标 “Missing datePublished”。常见非法写法：
-
datetime="2026/06/23"→ 斜杠不合法，必须用短横：2026-06-23 -
datetime="2026-6-23"→ 月份/日期没补零，应为2026-06-23 -
datetime="2026-06-23 10:00"→ 缺T分隔符，正确是2026-06-23T10:00 -
datetime="2026-06-23T10:00+08"→ 时区偏移必须带冒号：+08:00 -
datetime="2026-06-23T10:00 CST"→ 非标准缩写，只接受Z或±HH:MM
验证方法：DevTools → Elements 面板中右键检查 time 元素 → 确认 datetime 属性存在且值为纯字符串（不是灰色“未定义”）。
什么时候该用 time 标签，什么时候不该硬套
time 是语义开关，不是“所有带时间字样的内容都该包一层”的装饰标签。关键判断标准是：能否提供机器可验证的**绝对时间点**或**明确时长**。
立即学习“前端免费学习笔记（深入）”；
- ✅ 该用：
<time datetime="2026-06-23">今天</time>（文章发布日）、<time datetime="PT45M">45分钟</time>（视频长度） - ❌ 不该用：
<time datetime="刚刚">刚刚</time>（相对时间无法静态表达）、<time datetime="9:00–18:00">营业时间</time>（无具体日期，无法解析为唯一时间点） - ⚠️ 模糊场景妥协方案：如“下周三”，不能填
datetime="next wednesday"（非法），只能先写一个确定值（如2026-06-25），再靠 JS 动态更新文本（datetime值保持不变）
JS 动态生成 datetime 的三个高危陷阱
前端手拼或误用 API 极易导致 datetime 失效，尤其在跨时区场景下：
- ❌ 别用
toLocaleString()或toString()：输出类似"2026/6/23 下午9:04:00"，完全不符合 ISO 标准 - ❌ 别手拼
getFullYear() + '-' + (getMonth()+1)：漏补零（"2026-6-23"）、夏令时翻车、时区逻辑崩坏 - ❌ 别直接截
toISOString()当本地时间用：它返回 UTC 时间（如"2026-06-23T01:04:00Z"），若页面需北京时间，得显式加"+08:00"，不能靠“看起来像”来蒙混
安全写法：
UTC 时间用 new Date().toISOString().slice(0, 19) + 'Z'；
本地时间带偏移，优先用 Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Shanghai' }).formatToParts() 配合格式化逻辑。
显示文本和 datetime 可以分离，但语义必须一致
用户看到的内容（如“端午节”“早九点”）可以自由写，只要和 datetime 值逻辑对得上。但注意：
-
<time datetime="2026-06-23">端午节</time>合法，前提是上下文明确指 2026 年 6 月 23 日 -
<time datetime="2026-06-23T09:00+08:00">早九点</time>没问题，但datetime="早九点"就彻底无效 - 如果文本是“昨天”，
datetime仍必须填真实时间（如"2026-06-22"），不能为了“看起来对”而填占位符
最常被忽略的其实是时区一致性：同一页面里混用 +08:00 和 Z，或漏写时区导致不同设备解析结果偏差数小时——datetime 不是“差不多就行”的字段，它是机器唯一信任的时间源。
