用 <time></time> 标签标记时间，别用 <span></span> 或纯文本
HTML 有专门语义化标记时间的标签：<time></time>。它不只是视觉容器，还带机器可读的时间值（datetime 属性），对无障碍、SEO 和未来自动化处理都关键。很多人直接写“2024年3月15日”，或者套个 <span></span>，结果时间信息对屏幕阅读器或爬虫完全不可识别。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须提供
datetime属性，格式要符合 ISO 8601（如2024-03-15、2024-03-15T14:30、2024-03-15T14:30:00+08:00），浏览器不校验但解析工具依赖它 - 标签内容可以是人类友好的格式（如“昨天”“三小时前”），但不能为空；空内容会让辅助技术读成“时间”两个字，毫无意义
- 避免嵌套其他内联元素（比如
<strong></strong>）在<time></time>里——不是语法错误，但会干扰时间值的提取逻辑
datetime 属性格式错一个字符，机器就可能完全失效
常见错误是把 2024/03/15 或 15-03-2024 当作合法值塞进 datetime。浏览器不会报错，但 new Date("2024/03/15") 在某些环境（如 Safari）可能返回 Invalid Date，JS 解析失败；更严重的是，结构化数据测试工具（如 Google Rich Results Test）会直接忽略该 <time></time> 节点。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 日期部分必须是
YYYY-MM-DD（年-月-日），中间是英文短横线，不能是斜杠、点或中文字符 - 带时间时，必须用
T分隔日期和时间（如2024-03-15T10:20），不能空格 - 时区推荐显式写出（如
+08:00），不写则默认为本地时区，跨时区页面容易出偏差
动态生成时间时，服务端和客户端要统一时区解释逻辑
后端模板输出 <time datetime="2024-03-15">3月15日</time>，前端 JS 又用 Intl.DateTimeFormat 重渲染一次，结果用户看到两个不同日期——常见于未明确指定时区或误把 UTC 时间当本地时间渲染。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 如果后端已输出带时区的
datetime（如2024-03-15T00:00:00Z），前端 JS 应直接用new Date(时间字符串)解析，不要手动拆分年月日再构造 - 若后端只给日期（无时间部分），按规范应视为该时区当天的开始时刻（如
2024-03-15≡2024-03-15T00:00:00），但需确认业务是否真需要“全天”语义，还是隐含某个具体时刻 - 避免在 HTML 中写“刚刚”“1分钟前”这类相对时间——它们无法被静态抓取，且每次刷新都会变，破坏缓存和语义一致性
不支持 <time></time> 的老浏览器怎么办
IE 完全不识别 <time></time> 标签，但它的降级行为很友好：当作未知内联元素，仅丢失语义，不影响显示。真正的问题是 JS 操作时，document.querySelector("time") 在 IE9 及以下会返回 null。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不需要 polyfill 渲染，只需确保 JS 逻辑兼容：检查节点是否存在，或用
querySelectorAll("*[datetime]")作为兜底选择器 - 如果项目必须支持 IE8，可改用
<meta>标签在里声明时间（如<meta itemprop="datePublished" content="2024-03-15">），配合 schema.org 微数据，语义性不打折 - 注意：即使用了
<time></time>，也别指望它自动实现倒计时或日历联动——它只是标记，不是组件
时间标记最麻烦的从来不是怎么写，而是“谁来保证这个 datetime 值始终准确”。CMS 后台选了日期却没同步更新时间字段，API 返回的时间戳被前端错误截断，甚至编辑手输“2024-13-01”……这些才是线上最容易漏检的硬伤。
