<time> 标签仅用于语义化标记已有时间值，必须手动添加合规的 datetime 属性（如 2026-08-26），否则无法被机器识别；显示文本可任意，但 datetime 值须严格符合 ISO 8601 标准。
HTML 中的 <time> 标签不是“保存时间代码”的工具
它只是语义化标记已有时间值的 HTML 元素，浏览器不会自动从页面提取时间、写入或“保存”成 <time>。你得手动写，且必须符合规范，否则起不到结构化数据作用，搜索引擎和辅助技术也识别不了。
常见错误现象：<time>2026-08-26</time> 看似合理，但没 datetime 属性 → 机器无法解析为标准时间；又或者写了 datetime="今天" → 值非法，被忽略。
-
datetime属性值必须是合法的机器可读格式（如YYYY-MM-DD、YYYY-MM-DDThh:mm:ss、带时区的 ISO 8601） - 显示文本（即标签内文字）可以是任意人类可读形式，比如
<time datetime="2026-08-26">今天</time> - 不支持只靠 JS 动态插入后让
<time>自动生效——DOM 渲染完成时，datetime就该已存在
什么时候该用 <time>？别硬套
适用场景很明确：页面上出现的是**真实、固定、可验证的时间点或区间**，比如文章发布时间、活动开始时间、视频录制日期。
不适合场景：
立即学习“前端免费学习笔记（深入）”；
- 倒计时数字（用
<span>+ JS 更合适） - 用户输入框里的日期选择器（那是表单控件，不是语义时间）
- “3 小时前”这类相对时间（需服务端或 JS 渲染，
<time>本身不处理相对性） - 纯装饰性时间（如页脚“©2026”——直接写文本即可）
datetime 的合法写法和易错点
必须严格匹配 WHATWG HTML 标准定义的格式，否则会被解析为空或忽略。浏览器开发者工具里检查元素，能看到 datetime 是否被正确识别（例如在 Accessibility 面板中查看“Time”角色是否激活）。
- 日期：
datetime="2026-08-26"✅；datetime="26/08/2026"❌（非标准） - 带时间：
datetime="2026-08-26T09:47"✅；datetime="2026-08-26 09:47"❌（缺T分隔符） - 带时区：
datetime="2026-08-26T09:47+08:00"✅；datetime="2026-08-26T09:47 CST"❌（缩写时区不被接受） - 时间段：
datetime="2026-08-26T09:00/2026-08-26T12:00"✅（斜杠分隔起止）
服务端生成比前端 JS 拼接更可靠
如果你的网页由 PHP/Python/Node.js 等生成，直接在模板里输出合规的 <time> 最稳妥。JS 动态渲染容易出格式错误，而且搜索引擎爬虫可能不执行 JS，导致 datetime 缺失。
示例（Jinja2 模板）：
<time datetime="{{ post.published_at|isoformat }}">{{ post.published_at|strftime('%Y年%m月%d日') }}</time>
关键点：
- 确保后端时间对象调用的是标准序列化方法（如 Python 的
.isoformat()，JS 的.toISOString()） - 避免用字符串拼接构造
datetime值，哪怕看起来一样，也可能漏掉秒、时区或T - 静态站点生成器（如 Hugo、Jekyll）通常自带日期过滤器，优先用它们内置的 ISO 输出函数
真正麻烦的不是怎么写这个标签，而是确认时间源是否可信、格式是否全程一致、以及是否真有必要暴露为机器可读时间——很多所谓“时间标签需求”，其实只是想加个 CSS 样式或微数据，那用 <span class="date"> 更轻量、更可控。
