time标签的机器可读性完全取决于datetime属性是否合法：必须存在、为ISO 8601格式字符串（如2026-07-01T05:00:00+08:00），且不可动态修改；显示文本与datetime值必须解耦，非法格式或缺失属性将导致语义失效。
time 标签的机器可读性完全取决于 datetime 属性是否合法，不写或格式错一个字符，就等于没用。
datetime 属性必须存在且是 ISO 8601 字符串
浏览器、爬虫、屏幕阅读器只认 datetime 的值，不是标签里的文字。空属性、缺失属性、非法字符串，三者任一都会让语义失效。
-
datetime是强制属性，不能省略——<time>2026-07-01</time>和<span>2026-07-01</span>对机器来说没区别 - 值必须是字面量字符串，不能靠 JS 后续插入——Google Search Console 只解析 HTML 初始源码，动态塞进去的
datetime直接被忽略 - 验证方法：DevTools 里选中元素，看 DOM 中
datetime属性是否存在、值是否为纯字符串（非空、无空格、无中文、无斜杠）
ISO 8601 格式错一个字符就解析失败
不是“看起来像日期”就行，而是必须能被 new Date() 或结构化数据提取器无歧义识别。常见非法写法包括漏 T、用斜杠、月份不补零、时区缩写错误。
- 正确：
2026-07-01、2026-07-01T05:00:00+08:00、2026-07-01T05:00:00Z、PT2H30M - 错误：
2026/07/01（斜杠）、2026-7-1（缺前导零）、2026-07-01 05:00（缺T）、2026-07-01T05:00:00GMT+8（非标准时区） - Safari 对无秒数格式（如
2026-07-01T05:00）支持不稳定，建议统一写到秒级：2026-07-01T05:00:00
显示文本和 datetime 值必须解耦
这是最容易被卡住的设计点：人看的文本可以动态、模糊、本地化；机器读的 datetime 必须静态、精确、不可变。
立即学习“前端免费学习笔记（深入）”；
- 允许：
<time datetime="2026-07-01T05:00:00+08:00">刚刚</time>或<time datetime="2026-07-01T05:00:00+08:00">发布会当天</time> - 禁止：每次更新文本时同步改
datetime，比如把datetime改成"2026-07-01T05:00:00+08:00"→"2026-07-01T05:00:05+08:00"，原始时间点就丢失了 - 后端模板渲染时，别用
toLocaleDateString()拼接——它输出的是本地格式（如"2026/7/1"），应优先用toISOString().slice(0, 19)（UTC）或Intl.DateTimeFormat+formatToParts()构造带偏移的合法字符串
什么场景不该用 time 标签？
time 不是“所有带时间字样的内容都该套一层”的装饰工具，而是语义开关：开了就必须提供机器可验证的绝对时间点或明确时长。
- 营业时间
"9:00–18:00"没绑定具体日期，无法解析为唯一时间点，更适合用meta或 schema.org 标注 - 相对时间
"刚刚"、"下周三"、"月底前"——datetime无法表达模糊值，硬填会污染语义 - 仅用于样式控制（比如加个灰色字体）？直接用
span更合适，加time反而误导爬虫
最常被忽略的一点：datetime 值一旦写死，就再也不能改——它代表的是那个时间点本身，不是“当前页面加载时的时间”。动态倒计时、实时刷新的“X 小时后”，必须靠 JS 更新 textContent，但 datetime 属性从始至终保持不变。
