datetime属性必须严格遵循iso 8601标准：日期用yyyy-mm-dd，带时间需t分隔并显式标注时区（如+08:00或z），持续时间以pt开头；仅适用于可验证的绝对时间点或明确时长，不可用于相对时间、营业时间等模糊值。
datetime属性必须严格用ISO 8601，不是“差不多就行”
浏览器和搜索引擎只认标准格式，写错一个字符（比如漏掉 T、用斜杠代替短横、月份没补零）就会让 datetime 属性被完全忽略。这不是警告，是直接失效——document.querySelector('time').dateTime 会返回空字符串或 null，Google Rich Results Test 也识别不出 datePublished。
必须遵守的硬规则：
-
YYYY-MM-DD（如2024-05-20），不能是2024/05/20或2024-5-20 - 带时间必须有
T分隔：2024-05-20T14:30:00+08:00，不能写成2024-05-20 14:30:00 - 时区推荐显式写出：
+08:00或Z；仅写2024-05-20T14:30是合法但不推荐——它被解析为“本地时间”，而“本地”没有定义，不同设备结果可能不一致 - 持续时间必须以
PT开头：PT42M30S（42分30秒），不能写42分钟30秒或42:30
什么时候该用<time></time>，什么时候不该用
<time></time> 不是“所有时间都套一层”的装饰标签，它是语义开关：打开它，就得提供机器可验证的绝对时间点或明确时长。
该用的场景：
- 文章发布日期：
<time datetime="2024-05-20">五月二十日</time> - 会议开始时刻：
<time datetime="2024-05-20T14:00+08:00">下午两点</time> - 视频长度：
<time datetime="PT42M30S">42分30秒</time>
不该用的场景：
- 营业时间：
9:00–18:00—— 没绑定具体日期，无法解析为唯一时间点 - 相对时间：
刚刚、2小时后、下周三——datetime无法表达模糊值，硬填会语义污染 - 年份范围：
2020–2024—— 必须拆成两个<time></time>分别标起止，或放弃语义化
JS读取dateTime时的时区陷阱
time.dateTime 返回的是字符串，不是 Date 对象。直接传给 new Date() 容易出错，尤其遇到没带时区的格式（如 2024-05-20T14:30）。
不同浏览器对无时区时间的处理不一致：
- Chrome 可能按本地时区解释
- Safari 可能默认当 UTC 处理
- Firefox 行为又不同
安全做法是：只处理带完整时区信息的字符串，例如：
const el = document.querySelector('time');
const dtStr = el.dateTime; // "2024-05-20T14:30:00+08:00"
if (dtStr && dtStr.includes('T') && /[\+\-]?\d{2}:\d{2}$/.test(dtStr)) {
const date = new Date(dtStr); // 此时解析才可靠
}
如果后端输出不可控，建议统一用 toISOString() 或服务端生成带 +00:00 的 UTC 时间，避免客户端歧义。
文本内容可以人性化，但不能和datetime逻辑冲突
用户看到的文本（比如 昨天下午2:30）可以自由写，但前提是它真实对应 datetime 值所代表的那个时刻。
常见翻车点：
- 静态 HTML 里写
<time datetime="2024-05-20T14:30+08:00">昨天下午2:30</time>—— 如果今天是 5 月 21 日，它还成立；但如果页面缓存到 5 月 22 日，“昨天”就错成了“前天” - 用 JS 动态改
time元素的文本却不更新datetime—— 辅助技术读到的仍是旧时间戳
真正难的不是格式，是判断这个时间值是否值得暴露给机器。很多页面把 预计送达：约30分钟 硬套 <time></time>，datetime 只能填个固定值，反而让结构化数据失真。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
