<time> 标签的 datetime 属性必须为符合 ISO 8601 的字符串（如 "2024-05-09T07:51:00.123Z"），时间戳需先转换，否则机器不可读、语义失效。
直接说结论：<time> 标签本身不是时间戳标记工具，它只负责语义化“某个已知时间点”，而时间戳（如 1715269860123）必须先转成 ISO 8601 字符串，再填进 datetime 属性里，否则毫无机器可读意义。
为什么不能把时间戳数字直接塞进 <time>
浏览器和爬虫不认原始数字时间戳。比如写 <time datetime="1715269860123">现在</time>，datetime 值非法，所有结构化数据提取器（Google Rich Results Test、屏幕阅读器）会跳过该节点。ISO 8601 是唯一被广泛支持的格式，时间戳只是中间表示，不是最终交付形式。
- 时间戳是数值，
datetime属性要求字符串，类型不匹配 - 没时区信息：
1715269860123是毫秒数，但无法判断它是 UTC 还是本地时间，解析结果可能偏移 8 小时 - 服务端或 CMS 输出时若直接拼接时间戳，前端 JS 用
new Date(1715269860123)能解析，但 HTML 层已失去语义
怎么把时间戳转成合规的 datetime 值
关键在转换逻辑是否带时区且格式严格。用原生 JS 最稳妥的方式是 .toISOString()，它强制输出 UTC + Z 后缀；若需本地时区带偏移，则必须手动构造或借助 Intl.DateTimeFormat。
- UTC 时间（推荐）：
new Date(1715269860123).toISOString()→"2024-05-09T07:51:00.123Z" - 本地时区（显式偏移）：避免用
.toString()或.toTimeString()，它们不是 ISO 格式；可用Intl.DateTimeFormat("sv-SE", { timeZoneName: "short" })配合正则提取，但更稳的是用date-fns/formatISO(date, { format: "extended", representation: "complete" }) - 禁止行为：拼接
getFullYear() + "-" + getMonth() + 1...—— 容易漏补零、忽略夏令时、时区计算错误
<time> 的 datetime 值必须满足哪些硬性条件
格式错一个字符，机器就可能完全失效。不是浏览器报错的问题，而是下游工具（SEO 分析器、无障碍 API）直接丢弃该节点。
立即学习“前端免费学习笔记（深入）”；
- 日期部分必须是
YYYY-MM-DD，不能是2024/05/09、09-05-2024或2024-5-9 - 时间部分必须用
T分隔，不能空格；2024-05-09 07:51是非法值 - 时区必须显式写出：
+08:00或Z，不能省略；省略则按客户端本地时区解释，跨设备结果不一致 - 毫秒位数不限，但小数点后最多 3 位（
.123），多于 3 位部分会被截断或引发解析异常
动态内容中容易被忽略的时钟校准问题
用户本地时间不准，是“时间戳转显示”出错的最常见原因。比如你用 Date.now() 算出“5分钟内有效”，但用户手机快了 10 分钟，前端立刻判为过期——这不是代码 bug，是现实约束。
- 首次加载页面时，应发一次
/api/time请求获取服务器标准时间，算出偏移量并缓存 - 后续所有基于时间戳的判断（如倒计时、有效期、相对时间更新），都用校准后的时间，而非
Date.now() - 不要在 HTML 中硬编码
data-expire="1715269860123"就以为安全——它明文可见，可被篡改；真正校验必须落在服务端或 JS 加密签名验证环节
真正难的从来不是把数字塞进标签，而是确保这个数字背后的时间语义，在跨设备、跨时区、跨工具链的场景下依然无歧义。一旦漏掉时区、拼错分隔符、或混淆时间戳与 ISO 字符串的职责，整个语义化链条就断了。
