必须用的场景包括法律条款、考试题干、API字段说明等需交叉引用的文本，因其编号由浏览器自动维护，支持语义化跳转、屏幕阅读器播报序号、SEO提取流程结构及CSS/JS精准定位。

ol 适合表达有明确先后、层级或可引用顺序的内容，不是“带数字的列表”就该用它——用错反而破坏语义和可访问性。

哪些场景必须用 ol？

浏览器和屏幕阅读器会把 ol 解析为“序列容器”，其内部 li 的编号是自动计算、可被程序识别的。这意味着：

• 用户用键盘导航时，屏幕阅读器会报出“第2项，共5项”，而不是“数字2，文字xxx”
• SEO 工具能提取出“步骤1→步骤2→步骤3”的流程结构，增强内容可信度
• 后续 CSS 或 JS 可通过 ol li:nth-child(3) 精准定位第三步，而手动写 <p>3. xxx</p> 无法做到
• 法律条款、考试题干、API 响应字段说明等需交叉引用的文本，必须用 ol 才能支持类似“参见第4条”的语义化跳转

ol 和手动编号、ul + CSS 数字的区别在哪？

表面看都是“1. 2. 3.”，但底层行为完全不同：

立即学习“前端免费学习笔记（深入）”；

财经HTML高端海报生成

复杂得财经如何变成清晰，适合手机看的海报？如何加上你的IP

下载

• 手动编号（如 <p>1. 开始</p> <p>2. 执行</p>）：编号是纯文本，无法被辅助技术识别为序号，也不能响应 start 或 reversed 属性
• ul + list-style-type: decimal：视觉上像有序列表，但 DOM 中仍是无序结构，屏幕阅读器不会播报“第X项”，只当普通项目符号处理
• ol：编号由浏览器自动维护，插入/删除 li 后序号实时重排；start="5" 会让第一个 li 显示为“5”，且后续仍递增；reversed 会倒序渲染（如 3, 2, 1），这些都依赖原生语义

实际开发中容易踩的坑

多数问题出在“想省事”或“没注意属性优先级”：

• type 属性在 HTML5 中已废弃，不要写 <ol type="a"></ol>，改用 CSS list-style-type: lower-alpha
• value 写在 li 上会覆盖自动编号，但仅影响当前项；如果后续 li 没设 value，编号会从上一个值+1继续，不是重置——这点常导致序号错乱
• 嵌套 ol 时，子 ol 默认仍用阿拉伯数字，若需“1.1、1.2”，必须用 CSS 的 counter-reset/counter-increment 控制，不能靠 type
• 服务端渲染时若动态拼接 ol，要确保所有 li 都在 ol 内部闭合，漏掉 会导致后续 DOM 结构错位，尤其在 React/Vue 中 SSR 渲染易出问题

真正关键的不是“能不能加数字”，而是“这个顺序是否构成信息逻辑的一部分”。如果删掉编号不影响理解，那大概率该用 ul；如果编号本身承载含义（比如步骤不可跳过、条款具有法律效力、选项需按序引用），ol 就不是可选项，而是必选项。