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 格式化方法:
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
- 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 后续塞进去的。哪怕格式完全正确,动态插入也等于没写。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










