应使用标记时间线变更点，其datetime属性须为ISO 8601格式（如2024-03-15），内容可为人类可读文本；多个变更点需多个标签，辅以data-version等自定义属性标识版本；“前后对比”需用语义化容器（如）配合/标记小范围文本差异，禁用title或注释替代可见记录。
怎么用 <time></time> 标记时间线变更点
HTML 本身没有“时间线变更记录”原生语义标签，但 <time></time> 是唯一能正确表达机器可读时间的内置元素，适合标注每次调整发生的具体时刻。它不负责展示“前后对比”，只负责告诉浏览器和爬虫“这个文本代表一个确切时间”。
常见错误是把修改说明文字直接塞进 <time></time>，比如 <time>2024年3月上线新版导航</time> —— 这会让解析器误认为“2024年3月上线新版导航”是一个时间值，实际会失败或被忽略。
-
<time></time>的datetime属性必须是合法机器可读格式（如2024-03-15、2024-03-15T14:30），内容文本可以是任意人类可读形式（如“三月十五日”“v2.1上线日”） - 多个变更点就写多个
<time></time>，别堆在一个标签里 - 如果要强调“这是第几次调整”，用
data-version这类自定义属性辅助，<time datetime="2024-03-15" data-version="2.1">v2.1 上线</time>
HTML 中怎么呈现“调整前后对比”效果
纯 HTML 不提供对比视图能力，得靠结构设计 + 少量 CSS 辅助。核心思路是：用语义化容器区分“旧”“新”，再用视觉提示（如颜色、边框、删除线）强化差异。
典型错误是滥用 <del></del> 和 <ins></ins> 套整个段落——它们本意是标记编辑行为（类似 Word 修订模式），不是 UI 组件；过度使用会导致屏幕阅读器混乱，且无法响应式控制样式。
立即学习“前端免费学习笔记（深入）”；
- 用
<section></section>或带class的<div> 分隔不同版本，例如 <code><div class="version old">...</div>和<div class="version new">...</div> - 对具体变动字段，优先用
<del></del>（删掉的旧值）+<ins></ins>（新增的新值），仅限小范围文本级差异，如<p>状态：<del>草稿</del><ins>已发布</ins></p> - 避免嵌套
<del></del>/<ins></ins>多层，CSS 重置默认样式时容易冲突 - 真实变更记录需作为可见内容存在，哪怕默认折叠（用
<details></details>+<summary></summary>） - 如果必须隐藏，至少用
<span class="visually-hidden"></span>配合 aria-label，确保无障碍支持 -
title只适合极简提示（如缩写全称），别放日期、版本号、原因等结构化信息 - 时间值一律用 ISO 8601 格式：
YYYY-MM-DD（日期）、YYYY-MM-DDThh:mm（带时间），不要加中文、斜杠、空格 - 如果后端返回的是非标准格式，JS 渲染前必须转换，而不是靠
<time></time>自动修复 - 想让 Google 抓取到更新时间？除了
<time></time>，还得在加<meta name="last-modified" content="...">，两者格式必须一致
为什么不能只靠 title 或注释写变更说明
title 属性和 HTML 注释（<!-- ... -->）对用户不可见，也不被搜索引擎索引为内容主体，更无法被辅助技术稳定读取。它们不是“记录”，只是临时备注。
你写的 <p title="2024-03-15 修改字段校验逻辑">邮箱格式要求更新</p>，在键盘导航、语音朗读、打印页面时完全丢失上下文；而注释在 JS 动态渲染后可能被清除，也不参与 DOM 操作。
兼容性与机器可读性的实际取舍点
<time></time> 在所有现代浏览器中都支持，但部分旧版 Safari 对 datetime 的解析较弱；更重要的是，SEO 和结构化数据工具（如 Google Rich Results Test）只认标准格式，随便写 2024/03/15 或 2024年3月 会被忽略。
真正难的不是怎么标，而是谁来维护这些时间戳——手动填容易过期，自动化又得对接构建流程或 CMS。一旦时间值和实际内容脱节，语义就变成干扰信息了。
