必须用而非或，因其语义明确表示有序事件流，确保屏幕阅读器按序播报、打印序号不丢、缩放自动重排；读作“项目”，无序且易致时间逻辑失效。
直接用 <ol></ol> 搭结构，配伪元素画线和圆点，别碰 JS 渲染或 <div> 堆砌——管理系统里时间线最怕改需求、加节点、适配屏幕阅读器，语义化结构才是抗压底座。
<h3>为什么必须用 <code><ol></ol> 而不是 <ul></ul> 或 <div>
<p>时间线是天然有序事件流，<code><ol></ol> 的语义让屏幕阅读器按 1→2→3 顺序播报，打印时序号不丢，缩放后数字自动重排；换成 <ul></ul>，读屏器会说“项目一、项目二”，但不保证顺序；用 <div> 套 <code><p></p> 写“1.”“2.”，后端字段一改格式（比如从 “2024-05-01” 变成 “May 1, 2024”），序号就全乱套。更现实的是：运营明天要倒序展示“最新 5 条”，<ol reversed></ol> 一行 HTML 就搞定，不用动 JS 或后端 SQL。
<time></time> 的 datetime 属性怎么填才不被搜索引擎忽略
管理系统常从后端 API 拿到形如 "2026/10/19" 或 "2026-10-19 14:30" 的字符串，直接塞进 <time datetime="..."></time> 会失效。机器只认 ISO 8601 标准：
-
datetime="2026-10-19"（年-月-日）合法，"2026/10/19"不合法 - 带时间必须补零：
datetime="2026-10-19T14:30:00"，不能写"14:30"或"2:30 PM" - 时区必须显式：
datetime="2026-10-19T14:30:00+08:00"，"GMT+8"不被所有解析器支持 - 后端返回
"2026/10/19"？前端得先转：new Date("2026/10/19").toISOString().split('T')[0]
CSS 画主线和圆点，为什么不能用 border-left
给 <ol></ol> 加 border-left: 2px solid #ccc 看似快，但实际会引发三类问题：
立即学习“前端免费学习笔记（深入）”；
- 缩放时竖线位置偏移，尤其在 Chrome 高 DPI 屏幕下明显
- 打印预览中，边框可能被截断或错位
- 影响子元素 margin/padding 计算，导致节点文字换行后圆点悬空
- 正确做法：用
<ol>::before</ol>绝对定位画主线（position: absolute; top: 0; left: 50%; transform: translateX(-50%)），每个<li>::after</li>画圆点（position: absolute; left: 50%; top: 50%; transform: translate(-50%, -50%)）
管理系统里左右交替布局怎么兼顾可维护性
很多教程教用 li:nth-child(odd) 左对齐、li:nth-child(even) 右对齐，但真实系统里常要加“高亮当前节点”“折叠旧节点”“导出为 PDF”，这时硬编码奇偶逻辑反而难改。更稳妥的做法：
- 默认所有内容靠左，用
padding-left: 80px留出圆点空间，视觉清晰且易调试 - 真需要交错，用 class 控制：
<li class="timeline-item timeline-item--right">，CSS 写.timeline-item--right { text-align: right; }，而不是依赖序号 - 移动端一律单列堆叠，用
@media (max-width: 768px)把左右布局收为统一左对齐，避免横滑或溢出 - IE11 兼容要点：
<ol></ol>上加zoom: 1触发 hasLayout，否则伪元素可能不渲染
真正卡住开发的，从来不是“怎么画出那条线”，而是“运营下周要加个‘预计完成时间’字段，还要支持中英文切换”——结构语义化、时间格式标准化、样式与逻辑解耦，这三处没做稳，后面每加一个字段都是债务。
