time标签的datetime属性必须严格使用iso 8601格式，如“2024-05-01”或“2024-05-01t14:30:00z”，禁止中文、自然语言、本地化格式及常见错误（空格、时区缩写、缺零等），javascript应使用toisostring()而非toutcstring()。
time 标签的 datetime 属性必须用 ISO 8601 格式
浏览器只认标准 ISO 8601 时间字符串，写错格式会导致 datetime 完全失效（比如无法被屏幕阅读器识别、搜索引擎忽略时间语义）。不是“差不多能显示就行”，而是格式必须严格匹配。
-
datetime值不能是中文描述（如"2024年5月1日"）、自然语言（如"昨天"）或本地化格式（如"05/01/2024"） - 最简可用格式是
"YYYY-MM-DD"（日期），例如：<time datetime="2024-05-01">五月一日</time> - 含时间时必须带
T分隔符和时区信息，推荐用 UTC（Z）："2024-05-01T14:30:00Z" - 若用本地时间，需显式标注偏移，如北京时间写成
"2024-05-01T14:30:00+08:00"，不能省略+08:00
常见错误：漏掉秒、乱用空格、时区写错
这些看似小问题，实际会让 datetime 被解析为无效值——浏览器开发者工具里能看到 Element 面板中该属性灰掉或报 warning。
- 写成
"2024-05-01T14:30"（缺秒）→ 不合法。ISO 8601 允许省略秒，但 HTML 规范要求完整时间必须包含秒，建议统一写"2024-05-01T14:30:00Z" - 写成
"2024-05-01 T14:30:00Z"（T前有空格）→ 解析失败。T是固定分隔符，前后都不能有空格 - 写成
"2024-05-01T14:30:00GMT+8"或"2024-05-01T14:30:00CST"→ 无效。HTML 只接受±HH:MM或Z，不支持时区缩写 - 月份或日期用个位数不补零（如
"2024-5-1"）→ 不合法。必须是两位数："2024-05-01"
动态生成时注意 JavaScript 的 toISOString() 和 toUTCString() 区别
JS 里容易混淆这两个方法：只有 toISOString() 输出的是标准 ISO 8601 字符串，可直接塞进 datetime；toUTCString() 返回的是 HTTP 头风格字符串，完全不能用。
- ✅ 正确：
new Date().toISOString()→"2024-05-01T06:23:45.123Z"（毫秒可选，HTML 允许截断） - ❌ 错误：
new Date().toUTCString()→"Wed, 01 May 2024 06:23:45 GMT"（非 ISO 格式，不能用于datetime） - 如果要输出本地时间带偏移，用
new Date().toLocaleString("sv-SE", { timeZoneName: "short" })不可靠，建议手动拼接或用Intl.DateTimeFormat提取偏移再格式化
要不要加秒和毫秒？看场景
语义化时间不是越长越好。加不加秒、毫秒，取决于你是否真需要那个精度。
- 纯日期（如发布日、生日）：只用
YYYY-MM-DD，干净且无歧义 - 事件发生时间（如会议开始、订单创建）：至少到秒，即
YYYY-MM-DDTHH:MM:SSZ - 毫秒级时间戳（如性能打点）：HTML 允许保留毫秒（
"2024-05-01T14:30:00.123Z"），但多数场景没必要，反而增加体积 - 注意：
datetime是字符串属性，不是数值，不要传Date.now()或时间戳数字
真正麻烦的不是写法本身，而是团队协作时有人随手粘贴了错误格式，或者后端 API 返回的时间字段没做标准化处理就直接塞进 datetime。上线前用浏览器检查元素确认属性值是否高亮有效，比事后排查语义丢失更省事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
