time标签的datetime属性必须为ISO 8601格式，如2024-05-20或2024-05-20T15:30:00+08:00，不可含中文、空格或汉字单位；标签内文本可自由表达，但机器仅依赖datetime值解析时间。
time 标签的 datetime 属性必须是机器可读的 ISO 8601 格式
浏览器不解析 time 标签里的中文或自然语言时间（比如“昨天下午三点”），只靠 datetime 属性提供结构化时间数据。这个值不是随便填的，必须符合 datetime 属性规范 —— 实际上就是 ISO 8601 的子集。
常见错误是直接把显示文本复制进去：<time datetime="2024年5月20日">昨天</time>，这会导致解析失败、语义丢失，甚至影响 SEO 和屏幕阅读器识别。
-
datetime值不能含中文、空格、汉字单位（如“年”“月”“日”） - 日期部分必须为
YYYY-MM-DD（如2024-05-20） - 时间部分若存在，用
T连接，时区推荐用Z（UTC）或+08:00（如2024-05-20T15:30:00+08:00） - 只写日期时，
datetime就是纯日期；只写时间时，必须带T前缀（如T15:30），但不推荐单独用时间——缺少日期上下文，语义弱
datetime 属性和 time 标签内容可以完全不同
time 标签的视觉呈现（即标签内的文本）和 datetime 属性完全解耦。你可以用口语化表达，只要属性值准确即可。这对本地化、可访问性、数据提取都关键。
例如：
立即学习“前端免费学习笔记（深入）”；
<time datetime="2024-05-20T09:00:00+08:00">今天早上九点</time> <time datetime="2023-12-25">圣诞节</time> <time datetime="2024-01-01">元旦</time>
上面三个例子中，datetime 都是标准格式，而标签内文字自由表达，不影响机器理解。
- 搜索引擎和辅助技术只信任
datetime值，不读取标签内文字的时间含义 - JavaScript 读取
el.dateTime得到的就是原始字符串，需手动解析（如用new Date(el.dateTime)） - 不要为了“省事”让两者一致 —— 比如
<time datetime="今天">今天</time>是无效的，datetime不会被识别
不写 datetime 属性会怎样？
不写 datetime 属性，time 标签就只剩外观作用，失去语义价值。它不会报错，但等于没用 —— 对爬虫、语音朗读、日历集成等场景毫无帮助。
- W3C 明确建议：仅当能提供机器可读时间时才用
time标签 - 如果只有模糊时间（如“上周”“明年春天”），别硬套
time，改用普通span+ ARIA 或直接文案说明 - 动态生成时注意：服务端或 JS 拼接
datetime值，务必校验格式（可用正则/^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}:\d{2}([+-]\d{2}:\d{2}|Z)?)?$/粗筛）
datetime 在不同浏览器和工具链中的兼容性差异
所有现代浏览器都支持 datetime 属性解析，但工具链处理程度不一。比如某些静态站点生成器或 CMS 导出插件会忽略该属性，而部分富文本编辑器（如 TinyMCE）默认不暴露 datetime 编辑入口。
- Chrome / Firefox / Safari 都能正确将
datetime提供给屏幕阅读器（如 VoiceOver 会读出“2024年5月20日”而非“今天早上九点”） - Google Search Console 会提取
datetime用于富媒体搜索结果（如活动卡片），但要求值合法且与页面主题强相关 - Node.js 服务端渲染时，若用
jsdom测试，el.dateTime返回值是字符串，不会自动转成 Date 对象 —— 别假设它已解析
最常被忽略的是时区处理：很多人写 2024-05-20T15:30:00（没时区），浏览器按本地时区解释，可能和服务器预期不符。线上部署时，优先显式标注 +08:00 或 Z。
