ol标签的核心是声明内容的逻辑顺序而非仅控制编号样式，正确使用场景包括安装流程、法律条文、排名榜单；错误混用ul内容会导致语义污染，且ol只允许li为直接子元素，必须闭合，优先使用start、type、reversed等原生属性保障可访问性。
ol 标签不是“怎么写编号”的问题，而是“要不要声明顺序语义”的判断。用错标签，后续所有样式、JS 或无障碍支持都会打补丁。
必须用 ol 的三个典型场景
不是看要不要显示数字，而是内容本身是否具备不可颠倒的逻辑顺序：
- 安装或配置流程（如“1. 安装 Node.js → 2. 运行
npm install→ 3. 启动服务”） - 法律条款、协议条目（“第1条…第2条…”需被引用和跳转）
- 搜索结果排名、排行榜、考试题干选项（顺序即含义）
如果只是想“看起来像步骤”，但实际执行无依赖关系（比如产品特性罗列：“支持暗色模式、多语言、离线缓存”），就该用 ul —— 混用 ol 会让屏幕阅读器强行读出序号，造成语义污染。
ol 的基本结构与常见错误
合法结构只允许 li 作为直接子元素；任何文本、div、段落直接塞进 ol 都是无效 HTML，浏览器会自动纠错，但 DOM 结构可能错乱：
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误写法：
<ol>第一步<br>第二步</ol>（br不是合法子元素） - ❌ 错误写法：
<ol><div>第一步</div></ol>（div不被规范允许） - ✅ 正确写法：
<ol><li>第一步</li><li>第二步</li></ol>
漏闭合 li 或 ol 在开发中看似能渲染，但会导致：
- Vue/React 模板编译失败
-
document.querySelectorAll('li')返回节点数异常 - W3C Validator 报 warning，CI 流水线可能卡住
用原生属性控制编号，别过早碰 CSS
HTML5 提供了足够稳定的原生控制方式，优先用它们，而不是一上来就写 list-style-type：
-
start="3"：从 3 开始编号，适用于续接前文（如上一页结束于第 2 步） -
type="a"：小写字母（a, b, c），注意值只能是"1"、"a"、"A"、"i"、"I"，其他如"circle"是废弃值 -
reversed：布尔属性，让编号倒序（3, 2, 1），无需写reversed="true"
这些属性不依赖样式加载，打印、高对比度模式、辅助技术下都可靠。而用 CSS counter-reset 实现编号，一旦禁用样式，整个列表就变成无序文本——这不是“更灵活”，是主动放弃语义保障。
嵌套与可访问性容易被忽略的点
嵌套 ol 是允许的，但有硬限制：
- 内层
ol不继承外层start，比如外层start="5"，内层仍从 1 开始，需手动加start="1"或改用 CSS counters（仅当真需要“5.1、5.2”时） - 三层以上嵌套会显著降低可访问性，屏幕阅读器对层级的播报易混淆
- 若子项是解释性内容（如“数据库配置 → 连接地址：xxx”），更适合用
dl+dt/dd，而非强行塞进li
最常被忽略的是：列表结构一旦写错，后续所有 CSS 装饰、JS 交互、无障碍补救，都是在修一个本不该存在的漏洞。
