del标签的datetime属性必须严格遵循ISO 8601格式并加双引号，否则会被静默丢弃；合法写法包括纯日期、带时区的本地时间或UTC时间；动态生成须用toISOString()等安全方法，不可用toLocaleString()；仅内部草稿或临时调试可省略。
del 标签的 datetime 属性不是可选项，只要你想让“删除”这件事被机器、屏幕阅读器或法律存证系统识别，就必须加，且必须合法——写错等于没写。
del 的 datetime 属性必须带双引号且严格 ISO 8601
浏览器不校验、不报错、也不渲染它，但非法值会被静默丢弃。常见失效写法：datetime=2026-06-14（缺引号）、datetime="2026/06/14"（斜杠分隔）、datetime="2026-06-14 19:38"（缺 T 和时区）。合法写法只有：
-
datetime="2026-06-14"（纯日期，适用于仅需标记“哪天删的”） -
datetime="2026-06-14T19:38:00+08:00"（推荐，含时区，避免 Safari 等解析失败） -
datetime="2026-06-14T11:38:00Z"（UTC 时间，适合跨时区日志类场景）
注意：年月日、时分秒都必须补前导零；T 是字面量大写字母，不能换成空格或小写 t；+08:00 不能简写为 +8 或 GMT+8。
前端 JS 动态插入 del 时，别用 toString() 拼时间
直接调用 new Date().toString() 或手拼字符串极易出错：月份从 0 开始、漏补零、时区混乱。正确做法是：
- 要 UTC 时间 → 用
new Date().toISOString()（返回类似"2026-06-14T11:38:00.123Z"） - 要本地时区带偏移 → 用
Intl.DateTimeFormat("sv-SE", { timeZoneName: "short" }).formatToParts(new Date())配合手动组装，或更稳妥地引入date-fns/formatISO并传入{ format: "extended" } - 服务端渲染优先用原生输出：Python 的
datetime.isoformat()、Node.js 的toISOString()、Django 的{{ obj.updated_at|date:"c" }}
错误示例：del.setAttribute("datetime", new Date().toLocaleString()) → 返回中文或斜杠格式，语义立即失效。
立即学习“前端免费学习笔记（深入）”；
datetime 不显示，但影响可访问性和结构化数据提取
del 的 datetime 对视觉无影响，但它决定了下游工具能否理解“何时删”。关键影响点：
- 屏幕阅读器（如 NVDA）默认不朗读该时间，但开启详细模式（NVDA+Shift+D）后会读出“已删除，2026年6月14日”
- CMS 或文档比对工具依赖它排序修订块；格式错会导致时间戳为空，整段被排到最前或最后
- 法律/政务类页面若需留痕，W3C 明确推荐用
del datetime而非仅靠text-decoration: line-through——后者没有语义证据 - 搜索引擎虽不直接用它排名，但 Google Rich Results Test 等工具会检测并报告缺失或非法值
别指望用 aria-label 替代：它不参与结构化数据提取，也绕不过语义标准。
什么情况下可以不加 datetime？
只有两种真实场景可省略：
- 纯内部草稿，不对外发布，也不接入任何自动化流程（如 CI 构建、修订视图、审计日志）
- 临时调试用途，比如注释掉一段
<del>console.log('debug')</del>，且明确不构成业务变更
其余所有用户可见的业务动作——价格下架、条款更新、API 字段停用——都必须加，且必须合法。当前是 2026-06-14，如果你正在标记今天发生的删除，datetime="2026-06-14" 或带完整时间戳的版本就是你该填的内容。最容易被忽略的点是：没有视觉反馈，所以没人提醒你写错了——直到某天屏幕阅读器用户听不到时间，或法律存证时发现字段为空。
