标签必须设置符合 ISO 8601 标准的 datetime 属性（如 2026-04-17 或 2026-04-17T04:38:00+08:00），否则退化为普通容器，导致结构化数据失效、屏幕阅读器无法识别、插件无法提取时间。
用 datetime 属性
只写 是无效的——浏览器和搜索引擎不会识别它为时间语义。关键在于必须提供标准格式的 datetime 值，否则 就退化成普通内联容器。
常见错误现象：
– 页面显示正常，但结构化数据测试工具（如 Google Rich Results Test）提示“缺少 datetime”
– 屏幕阅读器读不出具体时间，只念“time”二字
– 日历类插件或 RSS 抓取器无法提取该时间点
-
datetime必须是 ISO 8601 格式：日期用YYYY-MM-DD，带时间则加T和Z或时区偏移，例如2026-04-17T04:38:00+08:00 - 如果只展示日期，
datetime可省略时间部分，但不能省略属性本身： - 用户看到的文本内容可以自由定制（如“昨天”“发布会当天”），但
datetime值必须精确、不可模糊
动态生成 datetime 要用 toISOString() 而非 toLocaleString()
想让 显示“刚刚”“2小时前”，同时保持机器可读性？那得把语义层（datetime）和表现层（textContent）分开处理。前者必须稳定、无歧义；后者才负责适配人类阅读习惯。
使用 new Date().toLocaleString() 直接赋值给 datetime 是典型错误——它输出的是本地格式字符串（如 "2026/4/17 上午4:38:00"），不符合 ISO 标准，解析会失败。
- 正确做法：用
new Date().toISOString()生成datetime值（如"2026-04-17T04:38:00.123Z"），再截取前 19 位（去掉毫秒和Z）即可用于大多数场景 - 若需保留本地时区而非 UTC，可用
new Date().toLocaleString("sv-SE", { timeZoneName: "short" })配合正则提取偏移，但更稳妥的是直接用Intl.DateTimeFormat构造器 +formatToParts() - 注意：
toISOString()返回的是 UTC 时间，如果你页面逻辑依赖本地时间（比如倒计时起点），得手动加上时区偏移再构造 ISO 字符串
配合 CSS 和 JS 实现“人看友好、机读准确”的双模显示
单纯靠 标签不能自动把 2026-04-17T04:38:00+08:00 渲染成“4 小时前”。你需要 JS 控制 textContent，同时确保 datetime 属性始终不变。
容易踩的坑：
– 每次更新 textContent 时误把新字符串也塞进 datetime，导致机器再也无法还原原始时间点
– 用 setInterval 不清理旧定时器，造成多个定时器同时修改同一个 元素，DOM 状态错乱
- 初始化时固定写死
datetime： - JS 中只更新
textContent，例如：el.textContent = "4 小时前"，绝不碰el.dateTime或el.setAttribute("datetime", ...) - 如需每秒刷新相对时间（如“4 小时 2 分钟前”），用
clearInterval(id)再setInterval(...)，避免叠加
SEO 和无障碍支持的关键细节常被忽略
的价值不在视觉，而在语义锚定。Google、Apple Shortcuts、Feedly 等工具都依赖它提取事件时间。但前提是它得“站得住脚”。
真实案例中高频出问题的点：
– 后端模板拼接时把变量直接插进 datetime，没做 ISO 校验，导致字段含空格或中文冒号
– 多语言站点用 toLocaleDateString() 生成 datetime，结果法语环境输出 "17/04/2026"，完全不可解析
- 上线前务必用浏览器开发者工具检查元素的
datetime属性值是否符合^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}这类基础正则 - 对屏幕阅读器友好：可在
外包一层，但不要替代datetime - 不要为了“看起来高级”而滥用——如果只是静态页上一个不变化的发布日期，
就已足够
