del标签的datetime属性必须是完整ISO 8601时间戳，含时区信息（如2024-05-20T14:30:00Z），仅日期或本地时间无效；它提供原生语义，支持可访问性、自动化处理与CSS选择器，需前后端统一转UTC确保有效性。
del 标签的 datetime 属性必须是完整 ISO 8601 时间戳
HTML 的 <del> 标签支持 datetime 属性，但它不是随便填个“2024-05-20”或“昨天”就能生效的——浏览器只认严格格式的 UTC 时间字符串。填错会导致属性被忽略，DOM 中存在但无实际语义，也无法被屏幕阅读器或数据提取工具识别。
正确写法必须包含时区信息，推荐用带 Z 的 UTC 时间（如 2024-05-20T14:30:00Z），或者带偏移量（如 2024-05-20T22:30:00+08:00）。只写日期部分（2024-05-20）不符合规范，多数浏览器会静默丢弃该属性。
-
datetime值不能含空格，必须用T分隔日期与时间 - 秒数可省略，但建议保留（
2024-05-20T14:30:00Z比2024-05-20T14:30Z更通用） - 服务端生成时，优先用
toISOString()（JavaScript）或datetime.isoformat() + 'Z'（Python）避免本地时区陷阱
为什么用 datetime 而不是 class 或 data-* 属性
单纯加 class="deleted-20240520" 或 data-deleted-at="2024-05-20" 看似简单，但绕过了 HTML 原生语义。这会让内容失去可访问性（AT 工具无法关联删除行为与时间），也阻碍了自动化处理——比如用 CSS 选择器 del[datetime] 批量提取所有带时间标记的删除记录，或用 JS 遍历 document.querySelectorAll('del[datetime]') 做审计日志。
原生 datetime 是唯一被 HTML 标准明确定义为“表示删除发生时间”的属性，语义明确、无需额外文档说明。
立即学习“前端免费学习笔记（深入）”；
- 搜索引擎和存档工具（如 Wayback Machine）可能解析并索引该属性
- 辅助技术（如 NVDA、VoiceOver）在朗读
<del datetime="...">时，可能附带时间提示（取决于具体实现） - CSS 中可用属性选择器做差异化样式：
del[datetime^="2024-"] { opacity: 0.7; }
服务端渲染时 datetime 容易漏掉时区转换
常见错误是直接把数据库里的本地时间（如 MySQL 的 DATETIME 字段）拼进 HTML，没转成 UTC。例如 PHP 中 date('Y-m-d H:i:s', $ts) 输出的是服务器本地时间，若服务器在东八区，却没加 +08:00，就变成无效值。
- Node.js：用
new Date().toISOString()安全；避免new Date().toJSON()（虽等价但语义模糊） - Python：用
dt.astimezone(timezone.utc).isoformat().replace('+00:00', 'Z') - PHP：用
$dt->setTimezone(new DateTimeZone('UTC'))->format('c')，再替换+00:00为Z（c格式输出带冒号，HTML 不认）
前端动态添加 del 时 datetime 必须实时生成
如果用户操作触发删除（比如点击“撤回编辑”按钮），不能复用初始渲染的时间，而应调用当前时刻。否则时间戳滞后于真实操作，破坏可追溯性。
示例（安全写法）：
const del = document.createElement('del');
del.datetime = new Date().toISOString(); // ✅ 自动带 Z，无需手动拼接
del.textContent = '已删除内容';
parent.appendChild(del);
- 不要用
new Date().toString()或toLocaleString()—— 格式不兼容 - 避免缓存时间变量（如
const now = new Date(); ... del.datetime = now.toISOString();），确保每个<del>的时间戳独立准确 - 若需精确到毫秒且兼容旧环境，
toISOString()已足够；不需要手动补零或截断
实际应用中，最常被忽略的是时区一致性——前后端都得明确“谁负责转 UTC”，而不是一方转、另一方假设已转。一旦时间戳无效，整个可追溯链条就断在第一环。
