ins/del 的 datetime 属性必须严格遵循 ISO 8601 格式（如 YYYY-MM-DDTHH:MM:SS±HH:MM 或 Z），否则浏览器忽略该值；它不控制样式但影响可访问性、数据提取及时序语义，需后端生成、注意时区对齐，并避免使用非标准时间字符串。
ins/del 的 datetime 属性必须是 ISO 8601 格式
浏览器只认标准时间字符串，datetime 值不是随便写个“2024-05-20”或“昨天”就能生效的。它必须符合 YYYY-MM-DDTHH:MM:SS 或更简略的 YYYY-MM-DD（但推荐带时分秒和时区）。不合规的值会被忽略，ins 和 del 就只剩样式，没了语义时间信息。
常见错误包括：
- 用中文或空格分隔日期时间（如
"2024年5月20日 14:30"）→ 浏览器静默丢弃 - 漏掉
T分隔符（如"2024-05-20 14:30:00"）→ 无效 - 没写时区且本地时间含夏令时风险 → 推荐显式写
Z（UTC）或+08:00
正确示例：<ins datetime="2024-05-20T14:30:00+08:00">新增内容</ins><del datetime="2024-05-19T09:15:22Z">已删除文本</del>
datetime 值不影响渲染样式，但影响可访问性和数据提取
ins 和 del 的下划线/删除线样式由 CSS 控制，datetime 本身不改变视觉表现。但它被屏幕阅读器读出，也被爬虫、CMS 或文档比对工具用来识别修改时序。
实际使用中要注意：
立即学习“前端免费学习笔记（深入）”；
- 服务端生成 HTML 时，务必用后端时间函数（如 Python 的
datetime.isoformat()、JS 的new Date().toISOString()）生成值，避免客户端时间不准 - 若内容由用户编辑后提交，
datetime应反映“保存时刻”，而非“编辑开始时刻” - 不要用
new Date().toString()—— 它输出的是非标准格式，datetime属性会失效
配合 aria-label 或 title 可补充人类可读的时间说明
屏幕阅读器默认读 datetime 值（如 “2024 年 5 月 20 日，下午 2 点 30 分”），但语音合成质量依赖系统，且普通用户 hover 也看不到。想兼顾可访问性和 UX，可以加 title 或 aria-label：
<ins datetime="2024-05-20T14:30:00+08:00" title="2024年5月20日 14:30 添加">关键参数</ins>
注意：title 在移动端基本不可见，aria-label 会完全覆盖元素文本（慎用）。更稳妥的做法是视觉上额外加一个 <small> 时间标注，保持语义与呈现分离。
和服务端时间戳对齐时，别忽略时区转换逻辑
前端 JS 获取的 new Date().toISOString() 是 UTC，而多数业务系统存的是本地时区时间（如东八区）。直接把数据库里的 2024-05-20 14:30:00 字符串硬塞进 datetime，没补时区偏移，就会错成 UTC 时间，显示早 8 小时。
安全做法：
- 后端统一以 UTC 存储并返回 ISO 字符串（如
"2024-05-20T06:30:00Z"），前端直接透传 - 若后端返回无时区时间字符串，前端需明确构造带偏移的
Date对象再转 ISO，例如：new Date("2024-05-20 14:30:00 +0800").toISOString() - 绝对不要靠
toLocaleString()拼接——它不保证 ISO 格式，且 locale 差异会导致解析失败
时区错一位，datetime 就失去可信度，协作场景下容易引发版本误解。
