del 和 ins 必须成对使用、严格闭合，datetime 属性须为 ISO 8601 格式（如 2026-06-03T23:28:00Z），cite 应指向可验证依据，禁止嵌套块级元素，导出时需手动处理 fallback。
必须成对使用、严格闭合、datetime 属性须为 ISO 8601 格式（如 2026-06-03T23:28:00Z），否则屏幕阅读器不播报、CMS 工具忽略修订、导出时痕迹丢失。
del 和 ins 必须成对出现才有语义价值
单独写 <del>旧文案</del> 或 <ins>新文案</ins> 只是加样式，不构成“修订”——浏览器和辅助技术无法推断这是替换动作。真正表达“改了什么”，得靠逻辑配对：
- 物理位置相邻更可靠：比如
<p>由 <del datetime="...">A</del> 改为 <ins datetime="...">B</ins></p> - 不能靠空格或换行“隐式配对”：HTML 解析器不认缩进，
<del>A</del><br><ins>B</ins>在部分编辑器里会被截断 - 避免跨段落配对：在第一个
<p>里开<del>，到第二个<p>才闭合，浏览器会自动补全闭合标签，DOM 结构不可控
datetime 属性格式错等于没写
时间戳不是装饰，是机器可读的关键字段。非法格式不会报错，但会被所有严肃工具跳过：
- ✅ 正确：
datetime="2026-06-03T23:28:00Z"（UTC）、datetime="2026-06-03T15:28:00+08:00"（带时区） - ❌ 无效：
datetime="2026/06/03"（斜杠分隔）、datetime="2026-06-03"（缺时间）、datetime="2026-06-03 23:28"（缺T和时区） - 前端用
new Date().toISOString()生成时，注意用户本地时区偏差；建议从后端注入或 Git 提交时间中提取并补全秒级精度与Z
cite 属性不是备注，而是可验证依据
cite 的作用是回答“为什么删/为什么加”，不是写“运营调整”这种模糊说明：
立即学习“前端免费学习笔记（深入）”；
- ✅ 有效：
cite="https://our-cms.example.com/changes/PR-789"（指向真实 PR 页面）、cite="/policies/v3#sec-4.2"（内部文档锚点） - ❌ 无效：
cite="编辑确认"（纯文本无链接）、cite=""（空值）、cite="https://example.com/404"（404 链接） - 多个修订共用同一原因？可以复用同一个
cite，但每个datetime必须独立准确
嵌套和块级包裹极易破坏结构
<del> 和 <ins> 是 inline 元素，强行当容器用会触发浏览器隐式修正，导致 DOM 不稳定：
- ❌ 危险写法：
<ins><p>新增段落</p><ul><li>项1</li></ul></ins>—— 段间距塌陷、列表缩进丢失，React/Vue diff 可能失效 - ✅ 推荐做法：拆成内联粒度，例如
<p><ins>新增首句</ins></p><p><ins>新增次句</ins></p> - 若真需包裹块级内容，必须显式加 CSS：
ins, del { display: inline-block; }，且仅限简单结构；复杂布局优先走 DOM 操作而非语义标签包裹
最常被忽略的一点：导出为纯文本或 PDF 时，<del> 和 <ins> 默认消失，只剩内部文字。没有通用 fallback，必须提前约定规则——比如服务端生成 plain text 时转成 [DEL]xxx[/DEL]，或 JS 提取时手动加前缀 -/+。
