datetime属性必须是静态、合法、初始加载即存在的ISO 8601字符串，否则机器直接忽略；需严格符合格式（如2026-08-10T21:47:00+08:00），禁止拼接或动态修改，应使用各语言原生ISO格式化方法生成。
datetime 属性必须是静态、合法、初始加载即存在的 ISO 8601 字符串，否则机器（爬虫、SEO 工具、屏幕阅读器）根本不会识别它——不是“读不准”，而是直接跳过。
datetime 值必须严格符合 ISO 8601，错一个字符就失效
浏览器不报错，但 Google Rich Results Test、W3C Validator、Feedly 等工具会静默忽略。关键不是“看起来像时间”，而是能否被 Date.parse() 或结构化解析器无歧义接受。
- ✅ 合法：
2026-08-10、2026-08-10T21:47:00+08:00、2026-08-10T13:47:00Z - ❌ 无效：
2026/08/10（斜杠）、2026-8-10（缺前导零）、2026-08-10 21:47（缺T）、2026-08-10T21:47:00GMT+8（非标准时区） - 常见陷阱：后端模板用
toLocaleDateString()拼接，输出"2026年8月10日"或"2026/08/10"—— 这些对机器完全不可读
后端或模板中生成 datetime 的安全做法
别拼字符串，优先调用语言原生的 ISO 格式化方法：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- Python：
dt.isoformat()（返回带Z的 UTC 时间），需手动替换为+08:00若需本地时区 - PHP：
$dt->format('c')（输出含时区的完整 ISO 字符串） - Node.js：
new Date().toISOString()返回 UTC，若需北京时间，用Intl.DateTimeFormat构造：const parts = new Intl.DateTimeFormat('sv-SE', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false, timeZone: 'Asia/Shanghai' }).formatToParts(); const dtStr = `${parts[0].value}-${parts[1].value}-${parts[2].value}T${parts[3].value}:${parts[4].value}:${parts[5].value}+08:00`;
前端 JS 动态更新显示文本时，千万别动 datetime
很多倒计时页面用 JS 把 <time datetime="2026-08-15T20:00:00+08:00">距直播还有 5 天</time> 改成 “还剩 4 天 23:59:59”，这是正确做法；但若顺手把 datetime 也改成新字符串，原始时间点就永久丢失了。
立即学习“前端免费学习笔记（深入）”；
-
datetime是事实锚点，只应写死一次，且必须是真实发生/计划的时间点 - 显示文本可任意变化：
刚刚、昨天、下周二都行，只要和datetime在逻辑上自洽（比如页面生成于当天，datetime="2026-08-10"+ 文本今天才合理） - JS 读取时用
el.getAttribute('datetime')，不要依赖el.dateTime（IE 不支持该属性）
最容易被忽略的是：机器读取的是 HTML 初始源码里的 datetime 值，不是你 JS 后续塞进去的。哪怕格式完全正确，动态插入也等于没写。
