必须用，因为时间轴是强时序流程（如“待审核→已通过→已发布”），仅能被读屏器、搜索引擎原生识别为有序步骤；语义无序，无列表语义且需手动维护可访问性属性。
直接用 <ol></ol>，别套 <div class="timeline"> —— 否则进度状态无法被读屏器识别、SEO 抓不到顺序、打印出来只剩一团文字。
<h3>为什么必须用 <code><ol></ol> 而不是 <ul></ul> 或 <div>
<p>管理系统的时间轴本质是「带状态的有序流程」，比如「待审核 → 已通过 → 已发布 → 已归档」。这种强时序+状态跃迁逻辑，只有 <code><ol></ol> 能被浏览器、爬虫、读屏器原生理解为“第1步→第2步→第3步”。
常见翻车点：
-
<ul></ul>语义是“无序”，一旦后端返回顺序错乱（比如状态字段为空），前端渲染不出错，但用户根本察觉不到流程已中断 <div> 套多层结构会让 JS 动态更新某一步状态（如把“已通过”改成“驳回重提”）时，必须手动维护 DOM 序号、aria-label、tabindex，极易漏掉可访问性属性 <li>纯 CSS 实现的“视觉序号”（比如用 <code>::before { content: "1." }）在打印预览或邮件客户端里直接消失- 只接受 ISO 8601：完整日期用
datetime="2026-10-20"，仅年月用datetime="2026-10"，带时分秒必须补零：datetime="2026-10-20T07:59:00+08:00" - 后端返回
"2026/10/20"？前端必须转：new Date("2026/10/20").toISOString().split('T')[0]再赋值，不能直接塞进去 - 避免用
pubdate—— HTML5.1 已废弃，Chrome 120+ 开始警告，部分审计工具直接忽略 - 主轴线用
<ol>::before</ol>：绝对定位 +transform: translateX(-50%)锚定中心，不占布局空间 - 每个节点圆点用
<li>::after</li>，同样绝对定位在中线上，避免因内容高度不同导致圆点上下漂移 - 左右交替排版靠
li:nth-child(odd)/li:nth-child(even)控制text-align和padding-left/padding-right，不要用 JS 判断奇偶——管理系统常要支持离线缓存，JS 可能未加载完就渲染 - 给
<ol></ol>设min-height: 100vh或用 JS 动态设style.height = Math.max(document.body.scrollHeight, window.innerHeight) + "px"，否则内容少于一屏时中轴线压根不显示 - @media (max-width: 768px) 里，把
<li>改为flex-direction: column，时间块用order: -1提前，确保「2026-10-20」始终在描述文字上方 - 禁用
white-space: nowrap在时间字段上——管理系统常要显示「2026-10-20 07:59:00」，强制不换行会导致窄屏溢出或遮挡圆点
<time></time> 的 datetime 属性怎么填才让系统能自动解析进度时间
管理系统常需对接日历、BI 工具或审计日志，<time></time> 的 datetime 必须是机器可解析格式，否则「2026年10月20日」这种写法等于没写。
实操规则：
CSS 画中轴线时，为什么不能用 border-left 直接加在 <ol></ol> 上
管理系统时间轴常需高精度对齐（比如审批节点与 PDF 签章位置对应），border-left 会参与盒模型计算，导致所有 <li> 的 left/right 偏移量浮动，缩放或打印时竖线错位。
正确做法（兼容 IE11+）：
响应式下进度时间轴断裂或节点堆叠怎么办
移动端窄屏时，常见现象是中轴线断成几截、节点文字换行后圆点偏移、甚至整个 <ol></ol> 高度塌陷看不见线——本质是容器没撑开高度，且 flex 换行逻辑失控。
关键修复点：
最易被忽略的是：管理系统时间轴常嵌在 iframe 或弹窗里，此时 100vh 是父页面视口高度，不是当前容器高度。得用 getBoundingClientRect() 算实际可用高度，再动态设置中轴线伪元素的 height。
