time标签的datetime属性必须严格使用iso 8601格式，如“2024-03-15”或“2024-03-15t14:30:00+08:00”，禁止中文、斜杠分隔、缺零、漏t或无时区；人眼内容置于标签体内，机器仅解析datetime值。
time 标签的 datetime 值必须是机器可读的 ISO 8601 格式
浏览器不解析 time 标签内文本内容，只认 datetime 属性。如果填 datetime="2024年3月15日" 或 datetime="Mar 15, 2024"，语义无效，辅助技术、搜索引擎和脚本都可能忽略该时间信息。
正确做法是严格使用 ISO 8601 标准：
-
datetime="2024-03-15"（仅日期） -
datetime="2024-03-15T14:30"（本地时间，无时区，不推荐） -
datetime="2024-03-15T14:30:00Z"（UTC 时间，推荐） -
datetime="2024-03-15T14:30:00+08:00"（带时区偏移，也合法）
注意：T 和 Z 是固定字符，不可省略或替换为空格；2024-03-15 14:30 是无效值，会降级为纯文本语义。
显示内容可以自由格式，但别和 datetime 冲突
time 标签的子文本是给人看的，可以写成「去年冬至」「上周三」「农历腊月廿三」，但前提是 datetime 仍指向精确的 ISO 时间点。否则语义断裂——机器拿到模糊值，人看到精确值，反而更难理解。
常见错误场景：
- 用
datetime="2024-03-15"，却显示发布时间：3小时前（动态内容需服务端或 JS 更新datetime，否则过期） - 显示「2024/03/15」但
datetime="2024/03/15"（斜杠分隔不是 ISO 格式，解析失败） - 中文「下午 2:30」对应
datetime="14:30"（缺日期，不完整）
JavaScript 读取 datetime 时要注意类型转换
time 元素的 datetime 属性始终是字符串，即使你写了 datetime="2024-03-15T14:30Z"，JS 里 el.dateTime 还是字符串。直接传给 new Date() 多数情况能解析，但有坑：
-
new Date("2024-03-15")→ UTC 零点（不是本地日期） -
new Date("2024-03-15T14:30")→ 无时区时按本地时区解释，不同设备结果不一致 - 稳妥做法：
new Date(el.getAttribute("datetime"))，依赖浏览器对 ISO 字符串的标准解析
若需确保时区行为一致，建议统一用 UTC 格式（结尾带 Z），再用 toLocaleString 转成本地显示。
SEO 和屏幕阅读器实际依赖 datetime 的完整性
Google 结构化数据测试工具会校验 time[datetime] 是否符合 W3C 规范；NVDA、VoiceOver 等读屏软件在遇到 time 标签时，会优先朗读 datetime 解析后的时间（如“2024年3月15日”），而非标签内文字——除非 datetime 无效，才会退回到读文本。
所以：
- 不要为了“好看”而牺牲
datetime的规范性 - 避免用
datetime存非时间信息（如版本号"v2.1"），那不是它的用途 - 批量生成页面时，务必检查模板中
datetime是否被错误拼接（比如漏了T或时区）
最常被忽略的是时区表达：写 +00:00 和 Z 等价，但 +0 或空时区声明（2024-03-15T14:30:00）会让解析结果随用户本地设置漂移。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
