datetime属性是<time>标签的强制入口，必须存在且符合ISO 8601标准格式（如2026-06-13T22:50:00+08:00），否则机器无法解析；显示文本可与datetime值不同，但后者须绝对、无歧义、不可动态更改。
datetime属性不写就等于没用
不加 datetime 的 <time> 标签，对搜索引擎、屏幕阅读器和 JS 来说，和普通 <span> 没区别。“昨天”“三分钟前”“2026年6月7日”这些文本人类能看懂，但机器无法解析、排序或转时区。它不是可选项，是强制入口。
常见错误现象：<time>昨天</time> 或 <time>2026/06/07</time>——这类写法会让语义化完全失效，结构化数据提取工具（如 Google Search Console）直接忽略。
- HTML 初始加载时，
datetime属性就必须存在且值合法；不能靠 JS 后续动态塞进去再指望爬虫识别 - 后端模板拼时间时，别用
toLocaleDateString()直接赋值，得先转成toISOString()或手动格式化为YYYY-MM-DD - 即使显示文本是 “刚刚”，
datetime也必须是固定、无歧义的时间戳，比如"2026-06-13T22:50:00+08:00"
ISO 8601 格式错一个字符就解析失败
浏览器和爬虫只认标准格式，错一个字符（比如小写 t、缺 T、用斜杠代替短横线）就解析失败。关键不是“看起来像日期”，而是能否被 new Date() 或结构化数据解析器无歧义识别。
正确写法分五类，按场景选：
立即学习“前端免费学习笔记（深入）”；
- 仅日期：
2026-06-13（注意：2026-6-13缺前导零，不合法） - 日期+时间（本地时区）：
2026-06-13T22:50:00（不推荐，时区隐含，JS 解析结果可能因用户设备而异） - 带显式时区（推荐）：
2026-06-13T22:50:00+08:00或 UTC 写法2026-06-13T14:50:00Z - 仅时间（限上下文已知日期）：
22:50或22:50:00（单独用于文章发布时间会丢失语义） - 持续时间：
PT2H30M（表示 2 小时 30 分钟），用于视频时长、服务周期等
错误写法示例：2026/06/13、2026-06-13 22:50（缺 T）、2026-06-13T22:50:00GMT+8（非 ISO 时区缩写）。
显示文本和 datetime 值可以完全不同
这是最容易被卡住的一点：你完全可以把 datetime 写死为绝对时间戳，而标签内文本写“刚刚”“还剩 1 天”“下周二”。二者职责分离——文本给人看，datetime 给机器读。
使用场景举例：
- 博客发布时间：
<time datetime="2026-06-11T14:22:00+08:00">2天前</time> - 活动倒计时页：
<time datetime="2026-06-15T20:00:00+08:00">距直播开始还有 2 天</time>（配合 JS 定时更新文本） - 多语言站点：en-US 下显示
Jun 13, 2026，zh-CN 下显示2026年6月13日，但datetime始终是2026-06-13
禁止把模糊表达塞进 datetime，比如 datetime="next Tuesday" 或 datetime="soon"——这些不是有效值，会被解析器丢弃。
动态生成时别用 toLocaleString() 填 datetime
前端 JS 生成时间时，最容易犯的错是把用户本地格式字符串塞进 datetime：
el.dateTime = new Date().toLocaleString(); // ❌ 输出类似 "2026/6/13 下午10:50:00"，完全不符合 ISO
正确做法：
- 用
toISOString()生成 UTC 时间，再截取并补偏移：new Date().toISOString().slice(0, 19) + "+08:00" - 若需保留本地时区而非 UTC，建议用
Intl.DateTimeFormat+formatToParts()构造，避免正则提取出错 - 每次更新显示文本（如“3小时前”）时，绝不能同步覆盖
datetime值——原始时间戳必须始终稳定
验证方式：打开浏览器开发者工具，选中 <time> 元素，检查 DOM 中 dateTime 属性是否真实存在且值未被清空（注意大小写：JS 中是 dateTime，HTML 中是 datetime）。
