有序列表的核心是语义化表达操作先后依赖关系,每个应为原子步骤,嵌套表示子步骤,禁用手动编号或非线性逻辑。

用 <ol></ol> 和 <li> 写出可读的操作步骤
HTML 有序列表不是为了“编号好看”,而是明确表达操作的先后依赖关系。浏览器默认用数字编号,但关键在语义——<ol></ol> 告诉解析器“这些项必须按顺序执行”,这对屏幕阅读器、自动化测试、甚至后续用 JS 提取步骤逻辑都直接影响。
实操时直接套用结构即可,不需要额外 class 或属性:
<ol> <li>打开终端</li> <li>进入项目根目录:<code>cd /path/to/project</code> </li> <li>运行构建命令:<code>npm run build</code> </li> </ol>
- 不要用
<div> + 手动写 “1. 2. 3.” —— 失去语义,也无法被辅助技术识别顺序 <li>每个 <code><li>应该是一个原子操作,避免把多步塞进同一个<li>里(例如“安装 Node.js 并验证版本”应拆成两项) - 如果某步含代码或路径,用
<code>包裹,不加引号、不加说明性文字如“输入:” -
start是数值型属性:<ol start="3"></ol>→ 第一项显示为 “3.” -
type控制符号:type="a"(小写字母)、type="I"(大写罗马)、type="1"(默认数字) - 注意:
type在嵌套<ol></ol>中会自动继承层级规则,但显式设置可覆盖,比如外层type="1"、内层type="a" - 避免混用
type和 CSS 的list-style-type,后者可能被禁用或不生效
修改起始编号或编号样式要用 start 和 type 属性
默认从 1 开始、用阿拉伯数字,但实际文档中常需跳号(比如接续上一节)或换格式(如字母、罗马数字)。这时靠 CSS 不够可靠,尤其在打印或某些邮件客户端里,得用原生属性。
嵌套有序列表表示子步骤时,结构比样式更重要
当某一步骤内部还有明确顺序的子动作(比如“配置 Webpack”包含“修改 webpack.config.js”“添加 loader”“重启服务”),就该用嵌套 <ol></ol>,而不是靠缩进或破折号模拟。
<ol>
<li>初始化 Git 仓库</li>
<li>提交初始代码,包含以下操作:
<ol>
<li>运行 <code>git add .</code>
</li>
<li>执行 <code>git commit -m "init"</code>
</li>
</ol>
</li>
</ol>
- 嵌套的
<ol></ol>必须直接放在父<li>内,不能放在段落或其他标签里,否则 HTML 结构非法 - 浏览器默认会缩进子列表,但不要依赖这个视觉表现来传达层级——语义本身已足够
- 别为了“看起来整齐”而强行扁平化嵌套,比如把子步骤提到同级再加“→”符号,这会破坏操作流的因果关系
别用 <ol></ol> 替代流程图或条件分支
有序列表只适合线性、无跳转、无判断的操作链。一旦出现“如果 X 成功,执行 Y;否则执行 Z”,或者“根据系统类型选择 A 或 B”,<ol></ol> 就不再适用。
- 这类情况优先用自然语言描述 +
<strong></strong>标出条件关键词(如 仅限 Windows、若未安装 Python) - 复杂逻辑建议配简图或用 Mermaid 语法生成流程图,而非硬塞进列表
- 有人用
value属性给<li>强行跳号来模拟分支(如<li value="5">…</li>),结果是编号断裂、语义混乱,且无法被自动化工具正确解析
真正难的不是怎么编号,而是判断哪些步骤必须保序、哪些可以并行、哪些根本不在同一路径上——这个判断错了,再标准的 <ol></ol> 也救不回来。











