del 的 datetime 属性是语义必需字段，必须存在且格式合法：仅支持“yyyy-mm-dd”“yyyy-mm-ddthh:mm:ss±hh:mm”“yyyy-mm-ddthh:mm:ssz”三种 iso 8601 格式，否则下游工具静默丢弃；前端应使用 toisostring() 或 intl.datetimeformat 等安全方法生成，不可手拼或用 tolocalestring()；它不参与样式渲染，专用于可访问性、修订比对与法律存证，仅在纯内部草稿或无时间敏感性的临时删除时方可省略。
del 的 datetime 属性不是可选项，是语义必需字段
只要你想让“删除”被机器识别——比如屏幕阅读器播报、CMS 工具比对修订、法律存证系统提取时间戳——datetime 就必须存在，且必须合法。不加，或加了但格式错，等于没加：浏览器不报错、不警告、也不渲染，只是静默丢弃整个属性。
常见错误包括：datetime=2026-06-22（缺双引号）、datetime="2026/06/22"（斜杠分隔）、datetime="2026-06-22 16:06"（缺 T 和时区）。这些写法在 HTML 中完全合法（解析器不会拒收），但所有下游工具都会跳过它。
真正起作用的只有三种合法形式：
-
datetime="2026-06-22"—— 纯日期，适用于仅需标记“哪天删的”，被解析为当日 00:00 UTC -
datetime="2026-06-22T16:06:12+08:00"—— 推荐，含本地时区偏移，避免 Safari 等解析失败 -
datetime="2026-06-22T08:06:12Z"—— UTC 时间，适合跨时区日志类场景，前提是时间源确为 UTC
前端动态生成 datetime 时，别用 toString() 或手拼字符串
直接调用 new Date().toString()、toLocaleString() 或手动拼接年月日时分秒，几乎必然出错：月份从 0 开始、漏补零、时区混乱、T 写成小写 t 或空格，全都会导致语义失效。
正确做法非常明确：
- 要 UTC 时间 → 用
new Date().toISOString()（返回类似"2026-06-22T08:06:12.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 不影响样式，但缺失会导致可访问性链路断裂
datetime 对视觉无任何影响，它不参与 CSS 计算，改样式也不会让它“生效”或“失效”。它的价值完全在结构层：屏幕阅读器（如 NVDA）开启详细模式后，会读出“已删除，2026年6月22日”；CMS 或文档比对工具依赖它排序修订块；法律类页面若需留痕，W3C 明确推荐此方式。
但要注意：主流屏幕阅读器默认不朗读该时间，必须用户主动触发（如 NVDA + Shift + D）；搜索引擎目前也未将其作为排名信号。所以它不是 SEO 工具，而是语义基础设施。
容易被忽略的关键点是：一旦 datetime 值非法，没有任何视觉或控制台提示，但整条可访问性链路就断了——你写了，等于没写。
什么时候可以省略 datetime？只有两种真实场景
不是“能省就省”，而是只有满足以下任一条件时才可不加：
- 纯内部草稿，不对外发布，也不接入任何自动化处理流程（比如本地 Markdown 预览）
- 内容删除不具时间敏感性，例如临时注释掉调试代码：
<del>console.log('debug')</del>
只要涉及用户可见的业务变更——价格调整、API 字段下线、政策更新、合同条款修订——就必须加，且必须严格符合 ISO 8601。当前时间是 2026-06-22，如果你标记的是今天发生的删除，datetime="2026-06-22" 是最简安全写法，但更推荐带上时分秒和时区偏移。
