必须为<time>标签添加合法ISO 8601格式的datetime属性，否则机器无法解析；正确格式包括仅日期（2026-06-07）、带时区的日期时间（2026-06-07T19:10:00+08:00）等五类，禁止模糊表达或错误分隔符。
datetime属性不写就等于没用
不加 datetime 的 <time> 标签，对搜索引擎、屏幕阅读器和 JS 来说，和普通 <span> 没区别。“昨天”“三分钟前”“2026年6月7日”这些文本人类能看懂，但机器无法解析、排序或转时区。它不是可选项，是强制入口。
常见错误现象：<time>昨天</time> 或 <time>2026/06/07</time>——这类写法会让语义化完全失效，结构化数据提取工具（如 Google Search Console）直接忽略。
- 必须写
datetime，且值必须是合法 ISO 8601 字符串 - 不能靠 JS 动态生成后塞进
datetime属性再渲染——HTML 初始加载时就得有正确值 - 后端模板拼接时间时，别用
toLocaleDateString()直接赋值，得先转成.toISOString()或格式化为YYYY-MM-DD
ISO 8601 格式怎么写才被机器认
浏览器和爬虫只认标准格式，错一个字符（比如小写 t、缺 T、用斜杠代替短横线）就解析失败。关键不是“看起来像日期”，而是能否被 new Date() 或结构化数据解析器无歧义识别。
正确写法分五类，按场景选：
立即学习“前端免费学习笔记（深入）”；
- 仅日期：
2026-06-07（注意：2026-6-7缺前导零，不合法） - 日期+时间（本地时区）：
2026-06-07T19:10:00（不推荐，时区隐含，JS 解析结果可能因用户设备而异） - 带显式时区（推荐）：
2026-06-07T19:10:00+08:00或 UTC 写法2026-06-07T11:10:00Z - 仅时间（限上下文已知日期）：
19:10或19:10:00（单独用于文章发布时间会丢失语义） - 持续时间：
PT2H30M（表示 2 小时 30 分钟），用于视频时长、服务周期等
错误写法示例：2026/06/07、2026-06-07 19:10（缺 T）、2026-06-07T19:10:00GMT+8（非 ISO 时区缩写）。
显示文本和datetime值可以完全不同
这是最容易被卡住的一点：你完全可以把 datetime 写死为绝对时间戳，而标签内文本写“刚刚”“还剩 1 天”“下周二”。二者职责分离——文本给人看，datetime 给机器读。
使用场景举例：
- 博客发布时间：
<time datetime="2026-06-05T14:22:00+08:00">2天前</time> - 活动倒计时页：
<time datetime="2026-06-10T20:00:00+08:00">距直播开始还有 3 天</time>（配合 JS 定时更新文本） - 多语言站点：
en-US下显示Jun 7, 2026，zh-CN下显示2026年6月7日，但datetime始终是2026-06-07
禁止把模糊表达塞进 datetime，比如 datetime="next Tuesday" 或 datetime="soon"——这些不是有效值，会被解析器跳过。
时区处理不当会导致 JS 解析偏差
如果你在前端用 new Date(el.dateTime) 获取时间，而 datetime 没有时区（如 2026-06-07T19:10:00），浏览器会按用户本地时区解释该时间，结果可能比你预期早/晚一整天。尤其跨时区内容（如全球直播、API 日志）必须显式声明偏移。
实操建议：
- 后端生成 HTML 时，优先输出带时区的完整时间，例如北京时间统一用
+08:00 - 若时间来自 JS
Date对象，用.toISOString()得到 UTC 时间，再替换Z为+00:00（避免部分旧环境不兼容Z） - 不要依赖
toJSON()或toString()，它们返回的字符串含空格、中文冒号或时区缩写，不符合标准 - 测试时用 Chrome DevTools 控制台执行
new Date("2026-06-07T19:10:00+08:00")看是否返回预期时间点
最隐蔽的问题是：HTML 里看着没问题，但 JS 脚本拿到的时间对象和原始意图差 8 小时——根源往往就藏在那个没写时区的 datetime 值里。
