ins标签的datetime属性必须严格遵循ISO 8601格式，如2024-03-15T14:30:00+08:00；其仅为元数据，不参与渲染，需配合CSS恢复下划线、JS读取或后端注入才能实现版本追溯。
ins标签的datetime属性格式必须是ISO 8601标准
<ins> 的 datetime 属性不是随便填个时间字符串就行，浏览器只认严格符合 ISO 8601 的格式。常见错误是写成 "2024-03-15 14:30" 或 "2024/03/15" —— 这些都不合法，会被忽略，datetime 就形同虚设。
正确写法必须带时区信息或明确标注为本地时间（用 Z 表示 UTC，或 +08:00 表示东八区）：
-
2024-03-15T14:30:00Z（UTC 时间） -
2024-03-15T14:30:00+08:00（北京时间） -
2024-03-15是允许的（仅日期，无时分秒），但语义弱，不推荐用于精确追溯
datetime不生效？检查是否被CSS覆盖了下划线样式
即使 datetime 值合法，也看不到下划线，大概率是 CSS 干扰了默认渲染。原生 <ins> 默认有 text-decoration: underline，但一旦全局重置了 text-decoration（比如 * { text-decoration: none; }），它就失效了。
解决办法很简单：
立即学习“前端免费学习笔记（深入）”；
- 显式恢复：加一条
ins { text-decoration: underline; } - 避免通配符重置影响语义标签，改用更精确的选择器（如只重置
a或span） - 不要依赖
datetime控制样式——它纯属元数据，不参与渲染
想用datetime做版本追溯？得靠JS或后端配合
datetime 本身只是静态属性，浏览器不会自动把它显示出来，也不会关联到任何日志或历史系统。想实现“点击下划线看到是谁、什么时候改的”，必须额外处理：
- 前端可监听
click，读取event.target.dateTime，再查本地映射表或发 API 请求 - 服务端渲染时，把
datetime和编辑者 ID、提交哈希一起注入，比如：<ins datetime="2024-03-15T14:30:00+08:00" data-editor="user_123"> - 注意：用户可随意修改 HTML 中的
datetime值，它不具备防篡改能力，仅作参考
和del标签的datetime用法完全一致，别分开记
<del datetime="..."> 和 <ins datetime="..."> 对 datetime 的格式要求、解析逻辑、用途边界完全一样。没必要为两者单独查文档，记住一个就够了。
真正容易被忽略的是：哪怕你填对了 datetime，也没人会主动去读它——除非你在界面上提供悬停提示（title）、工具栏按钮或专门的历史面板。元数据只有被消费才有意义。
