必须用 datetime 属性，否则 time 标签无语义价值；需用 ISO 8601 格式（如 2024-03-15T09:22+08:00）；支持持续时间（PT2H30M）；显示文本与 datetime 可分离；影响 SEO 和可访问性，但无性能开销。
time 标签该不该用 datetime 属性
该用，而且几乎必须用。不加 datetime 的 <time></time> 只是普通文本包裹，对机器（搜索引擎、屏幕阅读器、爬虫）毫无时间语义价值。
常见错误现象：<time>2024年3月15日</time> —— 看似合理，实则等于没写 <time></time>，因为无法被解析为可计算的时间点。
使用场景：文章发布时间、事件发生时间、倒计时起始点、日志条目时间戳等需要被程序识别的场合。
参数差异：datetime 值必须是规范的机器可读格式，优先用 ISO 8601：
立即学习“前端免费学习笔记（深入）”；
-
2024-03-15（日期） -
2024-03-15T14:30（带时间，缺省时区按本地处理） -
2024-03-15T14:30+08:00（显式时区，推荐） -
2024-W11-5（ISO 周格式，少见但合法）
datetime 值和显示文本不一致怎么办
完全允许，而且很常见。显示文本面向人，datetime 面向机器，二者职责分离。
比如中文“昨天”“上周三”“刚刚”这类相对时间，必须靠 JS 动态更新，但初始 HTML 仍需一个确定的 datetime 值供语义化使用。
实操建议：
- 静态内容直接写完整 ISO 时间 + 可读文本：
<time datetime="2024-03-15T09:22+08:00">3月15日上午9点22分</time> - 动态相对时间先写绝对值，再用 JS 替换显示文本（保留
datetime不变） - 避免把模糊表达塞进
datetime，如datetime="soon"或datetime="next week"—— 这些不是有效值，会被忽略
time 标签会影响 SEO 或可访问性吗
影响有限，但有明确信号价值。Google 和其他主流搜索引擎会提取 <time datetime></time> 中的时间信息用于富摘要（如新闻卡片的时间戳），屏幕阅读器也能播报其语义类型（“时间：2024年3月15日”），比纯文本更清晰。
性能 / 兼容性影响：零。它是个行内语义标签，无默认样式、无渲染开销，所有现代浏览器都支持，包括 IE9+。
容易踩的坑：
- 误以为加了
<time></time>就自动格式化或本地化 —— 它不做任何格式转换，显示全靠 CSS 或 JS - 在
<time></time>里嵌套其他块级元素（如<p></p>、<div>）—— 严格来说违反 HTML 规范，部分解析器可能降级处理 <li>用它替代 <code><meta>做页面发布日期 ——<meta>是给文档级元数据用的，<time></time>是给内容中具体时间点用的，用途不同 - 必须用大写
P开头，T分隔日期与时间部分（仅时间部分时可省略日期，直接PT...） - 常见写法：
PT30S（30秒）、PT1H（1小时）、P2D（2天）、PT1H30M（1小时30分） - 别写成
datetime="2h30m"或datetime="2:30"—— 这些不是标准格式，不会被识别为持续时间
要不要用 time 标签标记“持续时间”
可以，但要用 datetime 的特殊语法：以 P 开头的 ISO 8601 持续时间格式。
例如：<time datetime="PT2H30M">2小时30分钟</time> 表示一段时长，而非某个时刻。
注意点：
真正难的是判断一个时间值是否值得语义化：用户看到“2024-03-15”和机器能否理解它是同一天，中间差的往往就是那个不起眼的 datetime 属性。漏掉它，<time></time> 就只剩个空壳。
