必须使用ol标签实现步骤编号，因其语义明确、可访问性强且原生支持序号逻辑；ul适用于并列项（如配料），div无序号语义，手动编号会导致屏幕阅读器无法识别顺序、打印错乱及键盘导航断层。
ol 是唯一语义正确、可访问、且浏览器原生支持步骤编号的标签——别用 div + 手动写“1.”，也别用 ul 配 CSS 伪造序号，否则屏幕阅读器读不出顺序，打印时编号错乱，键盘导航跳过逻辑断层。
为什么必须用 ol 而不是 ul 或 div
菜谱步骤是强顺序依赖流程：漏掉第2步或调换第3和第4步，结果可能失败。HTML 的 ol 明确告诉浏览器和辅助技术“这是线性不可跳过的序列”。ul 表示并列关系（如配料表），div 则无任何语义。实测中，用 div 写“1. 热锅”会导致：
- 屏幕阅读器朗读为“1. 热锅”，但无法识别这是第几项、总共有几项
- 移动端缩放后，“1.” 和文字容易错位
- 无法用
start或reversed属性接续/倒序，改起来得重写全部 HTML
ol 基础写法与常见错误
正确结构极简：ol 只能直接包含 li，不能塞文本、p 或其他块级元素：
<ol> <li>将500ml水倒入锅中，大火烧开</li> <li>放入面条，中火煮3分钟</li> <li>捞出过凉水，沥干备用</li> </ol>
常见错误包括：
立即学习“前端免费学习笔记（深入）”；
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 在
ol里直接写文字：<ol>1. 烧水</ol>→ 浏览器不渲染编号，只当普通文本 - 用
p包裹li：<ol> <p></p> <li>...</li> </ol>→ 无效 HTML，部分浏览器会自动修正但行为不可控 - 嵌套错层：比如在
li里再开ol却没闭合，导致后续所有编号归零
用 type 和 start 处理多阶段步骤
一道菜常分“准备→烹饪→装盘”三阶段，每阶段需独立编号起点。此时不用 JS，纯 HTML 就能处理：
-
<ol type="a"></ol>→ 生成 a. b. c.，适合子步骤，如“腌制步骤：a. 加盐 b. 抓匀 c. 静置10分钟” -
<ol start="4"></ol>→ 从 4 开始编号，适合接续前文（比如上一页结束于第3步） -
<ol type="I" start="2"></ol>→ 显示 II. III. IV.，适合正式食谱文档风格 - 注意：
type合法值只有"1"、"a"、"A"、"i"、"I"；"circle"是ul的旧属性，对ol无效
响应式与可访问性关键点
移动端小屏下，ol 默认缩进可能挤压文字空间，但别直接删 padding-left —— 这会让序号“1.”贴着文字，破坏可读性。更稳妥的做法：
- 用
ol li { padding-left: 1em; }替代全局重置 - 若需隐藏原生序号做定制视觉（如圆角色块），必须保留
ol结构，并用list-style: none+::before伪元素仅装饰，不能删掉语义 - 每个
li内容尽量保持单句，避免长段落；如需换行，用br，不要塞p——p在li里虽合法，但会增加嵌套深度，影响语音朗读节奏 - 别忽略
reversed属性：倒计时类步骤（如“冷却倒计时：3分钟 → 2分钟 → 1分钟”）可直接<ol reversed></ol>
最易被忽略的是：步骤中出现条件分支（如“若酱汁浓稠，跳至第6步；否则继续熬煮2分钟”）时，ol 不能强行塞进一个列表里——它只表达确定顺序。此时应拆成主 ol + details 包裹分支说明，语义才干净。
