ins/del 的 datetime 属性必须加双引号，且值为合法 ISO 8601 格式（如"2024-03-15"或"2024-03-15T14:22:00+08:00"），否则浏览器忽略；语义用于可访问性和结构化数据，非SEO优化手段。
ins/del 的 datetime 属性到底要不要加引号
必须加双引号，且值必须是合法的 ISO 8601 时间字符串，比如 "2024-03-15T14:22:00+08:00" 或简写为 "2024-03-15"。不加引号、空格错位、用中文标点（如“”或：）都会让浏览器忽略该属性——它不会报错，但 datetime 就形同虚设。
常见错误现象：
-
<ins datetime="2024-03-15"></ins>→ 缺引号，解析失败 -
<del datetime="2024年03月15日"></del>→ 非 ISO 格式，被忽略 -
<ins datetime="2024-03-15 14:22"></ins>→ 缺失T和时区/偏移，部分浏览器（如 Safari）可能不识别
datetime 值写成日期还是带时间戳更好
取决于你标记的语义精度。如果只是说明“某段文字在某天被插入”，用 "2024-03-15" 完全够用；但如果涉及协作编辑、版本比对、或需和后端 API 时间戳对齐，就必须带上时分秒和时区，例如 "2024-03-15T14:22:07+08:00"。
注意点：
- 服务器生成 HTML 时，建议直接用后端时间库输出 ISO 格式（如 Python 的
datetime.isoformat()、Node.js 的new Date().toISOString()），避免手拼出错 - 前端 JS 动态插入
<ins></ins>时，别用new Date().toString()—— 它返回的是本地可读字符串，不是标准格式 - 时区推荐显式写出（如
+08:00），而不是用Z（除非你确定所有时间都按 UTC 存储）
screen reader 和 SEO 真的会读/抓取 datetime 吗
会，但有限。主流屏幕阅读器（NVDA、VoiceOver）在遇到 <ins datetime="..."></ins> 时，**默认不朗读该时间**，除非用户主动开启「详细模式」或使用特定快捷键（如 NVDA+Shift+D）。搜索引擎（Google、Bing）理论上能解析该属性，但目前没有公开证据表明它直接影响排名——它的价值主要在语义可访问性和结构化数据补充上。
实际建议：
- 不要指望靠
datetime提升 SEO，但它能让你的 HTML 更符合 W3C 推荐标准，尤其适合政务、出版、法律类需要留痕的场景 - 若真需要向用户明确传达修改时间，应在视觉层额外显示（比如小字标注「新增于 2024-03-15」），
datetime是底层语义支撑，不是替代方案 - 用
aria-label强行塞时间进去反而破坏语义，不推荐
和
不会冲突，但没必要嵌套。比如 <ins><time datetime="...">内容</time></ins> 是合法的，但属于冗余：因为 <ins></ins> 自身已有 datetime 属性，再套一层 <time></time> 并不能增强语义，还可能干扰辅助技术对修改事件的识别逻辑。
更合理的分工是：
- 用
<ins datetime="..."></ins>表达「这段文字是何时新增的」 - 用
<time datetime="..."></time>表达「内容本身代表的时间点」，比如会议时间、截止日期等 - 二者语义不同，强行合并会让机器难以区分「修改行为发生时间」和「内容所指时间」
时间格式容错性低，写错一个字符就失效；语义价值真实存在，但依赖正确使用和配套设计。
