必须用<ol>当内容有内在顺序（如安装步骤、法律条款、搜索排名），而非仅需编号；须显式闭合，嵌套宜浅；start和reversed是语义属性，不可用于视觉伪装，否则导致屏幕阅读器误读、DOM错乱及兼容性问题。
ol 列表不是“加个编号就完事”，语义错位、嵌套断裂、无障碍失效——这些问题往往在上线后才暴露，但根源都在第一行标签写法里。
什么时候必须用 ol 而不是 ul
只看内容有没有内在顺序，不看要不要显示数字。
- 用
ol：安装步骤、法律条款第1–5条、搜索结果排名、向导流程（“下一步”依赖上一步） - 用
ul：产品功能点并列、城市列表、导航菜单（无逻辑先后）、标签云 - 硬套
ol只为视觉编号 → 屏幕阅读器会读成“第1项、第2项…”，用户听到的是语义噪音，不是结构信息
start 和 reversed 的真实使用场景
这两个属性不是炫技工具，而是解决具体业务逻辑的补丁。
-
start="3"：适用于接续上一页的步骤（如分页教程，“步骤3”开始），但注意：它不改变 DOM 顺序，只改渲染序号 -
reversed：仅适合倒计时类列表（如“距截止还剩3天、2天、1天”），别用于“最新3条新闻”——那该用 JS 排序 +ol，否则语义反了 - 两者同时用会触发浏览器兼容性问题：Safari 16.4+ 支持，旧版 Edge 直接忽略
reversed，且start值可能被重置
嵌套 ol 时 DOM 结构最容易崩在哪
不是语法报错，而是浏览器自动纠错导致结构错位，后续 JS 拿不到预期节点。
- 漏闭合父级
ol：<ol><li>A<ol><li>B</ol></li></ol>→ 浏览器会把内层ol当作 A 的文本子节点，外层li实际没闭合 - 混用
ul和ol嵌套本身合法，但屏幕阅读器对层级感知混乱（例如“第1项，子项：圆点、圆点”，无法区分主次） - 三层以上嵌套基本放弃可维护性：CSS 选择器爆炸（
ol ol ol li）、缩进靠 padding 还是 margin 难统一、无障碍测试直接标红
CSS 替代 type 属性的实操要点
type 是 HTML4 遗留属性，现代项目中禁用它——不是因为它不能用，而是它和 CSS 冲突不可控。
立即学习“前端免费学习笔记（深入）”；
-
type="A"在 Firefox 中可能被list-style-type: upper-alpha覆盖，但在某些安卓 WebView 里又优先级更高，行为不一致 - 要自定义前缀（如 “Step 1.”），必须用：
ol { list-style: none; } ol li::before { content: "Step " counter(section) ". "; counter-increment: section; } -
list-style-position: inside看似省事，但换行时第二行文字会和符号左对齐，破坏阅读流；生产环境一律用outside+padding-left控制缩进
ol，而是写完之后没人再检查它是否还在表达“顺序”——当产品经理说“把步骤改成横向滚动”，工程师删掉 ol 换成 div，语义就彻底丢了。 
