<time>标签必须带合法ISO 8601格式的datetime属性，否则被完全忽略；显示文本与datetime需解耦，前者为人服务，后者为机器提供唯一可信时间锚点。
time 标签不加 datetime 就等于没写
浏览器、搜索引擎、屏幕阅读器完全忽略没有 datetime 属性的 <time>。写成 <time>2024年3月15日</time>，DOM 中 timeElement.dateTime 返回空字符串，Google Rich Results Test 会报 “Missing datePublished”。它不是“增强样式”的标签，而是语义开关——关了就无信号。
常见错误现象：
-
<time>昨天</time>—— 文本可读，但机器无法解析任何时间点 -
<time datetime="2024年3月15日">3月15日</time>——datetime值非法，直接被忽略 -
<time datetime="2024-3-15">3月15日</time>—— 月份/日期未补零，不符合 ISO 8601 字面要求
datetime 必须是字面级合法的 ISO 8601 字符串
不是“差不多像就行”，而是必须严格匹配 W3C 定义的五种格式之一。错一个字符（漏 T、用 /、时区少冒号）就失效，且不报错，静默丢弃。
合法格式仅限以下五类（选错会导致语义丢失）：
立即学习“前端免费学习笔记（深入）”；
- 纯日期：
"2026-06-23"（不能是"2026/06/23"或"2026-6-23"） - 纯时间：
"14:30"或"14:30:00"（仅适用于同日内固定时刻，如营业时间） - 日期+时间（无秒/无时区）：
"2026-06-23T14:30"（合法但不推荐，本地时间定义模糊） - UTC 时间：
"2026-06-23T06:30:00Z"（Z必须大写） - 带偏移的本地时间：
"2026-06-23T14:30:00+08:00"（+08:00不可简写为+08或CST）
验证方式：DevTools → Elements 面板检查 <time> 元素 → 确认 datetime 属性存在且值为上述任一格式（非灰色、非空）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
显示文本和 datetime 值可以且应该分离
<time> 的核心设计就是解耦：文本为人服务，datetime 为机器服务。二者不必字面一致，但逻辑必须对齐。
典型场景与写法：
- 文章发布时间显示“3小时前”，
datetime必须填绝对时间戳：<time datetime="2026-06-23T05:24:00+08:00">3小时前</time>（后续靠 JS 动态更新文本，datetime不变） - 活动页写“本周六上午9点”，
datetime填对应具体时间：<time datetime="2026-06-27T09:00:00+08:00">本周六上午9点</time></li> <li>中文友好格式：<code><time datetime="2026-06-23">6月23日（星期二）</time>
—— 括号内星期可由后端或 JS 计算生成，不影响datetime合法性
注意：datetime 里不能塞解释性文字，如 datetime="2026-06-23 (端午节)" 是无效的，机器只认纯 ISO 字符串。
别把 time 当装饰标签或时间计算器用
<time> 不做任何渲染、格式化、本地化或倒计时计算。它只是个语义容器，所有视觉效果和行为都得靠 CSS 或 JS 实现。
容易踩的坑：
- 以为加了
<time>就自动转成“昨天”“刚刚”——实际仍需 JS 调用Intl.RelativeTimeFormat或手动计算 - 在
<time>内嵌套<div>或<p>—— 违反 HTML 规范，部分解析器会降级处理为普通文本 - 用它标“v2.3.1”“订单#12345”“¥99”——这些都不是时间，滥用会干扰结构化数据提取
- 标营业时间“9:00–18:00”却填
datetime="09:00"—— 单点时间无法表达区间，应改用两个<time>或更合适的语义（如<meta>+ Schema.org）
真正关键的复杂点在于：当你需要动态更新显示文本（比如倒计时），datetime 属性必须保持原始绝对值不变——这是机器唯一能信任的锚点，所有相对计算都得围绕它展开，而不是反过来。
