ol是表达不可交换先后逻辑的语义容器，必须用于步骤、条款等有严格顺序的场景；ul仅表并列，dl表定义关系；误用会导致编号断裂、无障碍失效及样式异常。

不是“加编号的工具”，而是表达顺序关系的语义容器。用错地方，编号会断、屏幕阅读器会读错、CSS 样式会失效——这不是 bug，是你在用
做它不该做的事。

什么时候必须用

而不是

或

当内容存在不可交换的先后逻辑时，

是唯一正确选择：ol 表示“第 1 步必须在第 2 步之前”“第 34 条规则先于第 35 条生效”。

只表示“这些项目并列存在”，
则完全无序语义。
常见误用场景包括：
• 把操作步骤写成
+ 手动数字（如 <div>1. 打开电源</div>）
• 用
做面包屑导航（路径有明确层级顺序，ul 无法传达“首页 → 分类 → 当前页”的递进含义）
• 在法律条款或比赛规则中混用

和
，导致子项脱离父项语义上下文

start 和 type 属性的实际作用边界

start 控制的是浏览器自动计数的起点，不是“视觉上显示的首个数字”——它只对紧邻的 li 生效，且不继承到嵌套

中；type 指定编号样式，但现代开发中更推荐用 CSS 的 list-style-type 替代，避免 HTML 承担表现职责。
关键限制：
• start="34" 只影响外层
的第一个 li 显示为 “34.”，后续仍按 35、36 递增
• 嵌套的
必须完整写在某个 li 内部，否则浏览器不识别其从属关系
• type="I"（大写罗马数字）在部分旧版 Safari 中渲染异常，生产环境建议用 CSS counter-style: upper-roman 替代

嵌套

必须满足的 DOM 结构条件

嵌套失效的根源几乎全是结构错误：子

没被包裹在父 li 里，而是和父
1. 并列放在外层
   中。
   正确结构只有这一种：
   • 外层
   → 包含多个 li
   • 其中某一个 li 内部 → 直接写
   
   • 子
   内部 → 只能有 li，不能有

   、

   
   使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审
   使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。
   下载
   或文本节点直接子元素
   典型错误：
   • 把子规则写成 <p></p> <ol type="a">...</ol>（
   不是
   的合法父容器）
   • 在
   1. 外另起一个
      ，再用 CSS 缩进模拟嵌套（语义断裂，无障碍设备无法关联父子关系）
      • 给子
      加了 start="1" 却忘了它默认就是 1，反而造成编号重复或跳变

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

      CSS 隐藏编号但保留语义的可靠写法

      想让

      看起来像无序列表或自定义符号，又不破坏可访问性？list-style-type: none 是唯一安全方案。
      注意：
      • 必须作用于 li，不是
      （
      上设 list-style: none 有时会干扰计数逻辑）
      • 若需添加分隔符（如面包屑中的 “/”），用 ::before 或 ::after 伪元素，不要用实际字符硬编码
      • 对于仅前 N 项显示编号的场景（如只显示前 5 步），用 li:nth-of-type(-n+5) 控制可见性，而非删除后几项的 li 元素——删 DOM 会破坏语义完整性
      • 避免用 counter-reset + counter-increment 重写编号逻辑，除非你明确需要跨容器计数；原生
      计数对屏幕阅读器更友好，且无需 JS 干预 嵌套层级越深，DOM 结构容错率越低。哪怕多一个空格、少一个闭合标签，都可能让整个编号链断裂——这不是浏览器不兼容，是 HTML 解析器在严格执行语义规则。