核心是用<ol>包裹不可交换的线性步骤，每个步骤必须为<li>直接子元素；禁用div/p手动编号，否则破坏可访问性、SEO及自动编号；嵌套<ol>须置于<li>内；推荐CSS而非type/start控制编号。
ol 列表制作文章步骤说明，核心就一条：用 ol 包裹语义上不可交换的线性操作项，每个步骤必须是 li 元素，其他写法都算结构错误，后续可访问性、SEO 和动态维护都会出问题。
为什么不能用 div 或 p 手动编号
常见错误现象：<div>1. 准备材料</div><div>2. 混合原料</div> —— 看似能跑，但实际埋了三个坑：
- 屏幕阅读器读不出“这是第几步”，只会平铺播报文字，用户无法用快捷键跳转到某一步
- 若某步需动态隐藏（比如权限控制），编号得手动重算；而
ol在 DOM 中增删li后，浏览器自动重排序号 - 搜索引擎无法识别操作流程结构，降低页面在“教程”“步骤”类关键词下的权重
ol 的合法嵌套结构怎么写
嵌套本身合法，但必须严格遵守父子关系。错误写法：<ol><li>主步骤</li><ol><li>子步骤</li></ol></ol> —— 第二个 ol 会被浏览器移到外层，导致编号中断或语义断裂。
正确写法是子 ol 必须包在某个 li 内部：
立即学习“前端免费学习笔记（深入）”；
<ol>
<li>编译代码
<ol>
<li>安装依赖</li>
<li>运行构建命令</li>
</ol>
</li>
<li>部署服务</li>
</ol>
注意：li 内可嵌套任意内容（段落、标题、代码块），但直接子元素只能是 li，不能是 p 或 div 直出。
用 type 和 start 还是用 CSS 控制编号样式
type 和 start 属性虽仍有效，但现代实践中建议交由 CSS 处理，原因很实在：
-
type="I"在旧版 Safari 或某些 Android WebView 中可能渲染成阿拉伯数字，兼容性不可靠 -
start是静态值，JS 动态插入新li后，编号不会自动调整；而counter-increment可响应式更新 - CSS
list-style-type: lower-greek等值比 HTMLtype支持更多类型，且可统一主题管理 - 若要隐藏原生编号只留视觉装饰（比如带背景色的圆角数字），必须先清
list-style: none和padding-left: 0，否则缩进还在，对齐错乱
分支逻辑别塞进同一个 ol
有序列表表达的是确定、线性的顺序。如果某一步要根据条件跳转（如“登录成功 → 执行 A；失败 → 执行 B”），强行塞进一个 ol 会破坏语义：
- 屏幕阅读器无法理解“这一步之后可能走两条路”，逻辑断裂
- JS 判断分支时，DOM 结构和语义不匹配，容易写出脆弱逻辑
- 打印或高对比度模式下，CSS 伪元素生成的编号可能错位，原生
ol更稳
更合理的做法是主流程用 ol，分支用独立 ol 或 details 包裹，并用文字明确标注触发条件，比如：“若未登录，请先完成以下注册步骤：”。
最容易被忽略的一点：语义一旦写错，后期补救成本远高于初始选对标签。一个 ol 不只是“看起来像步骤”，它是 DOM 层面的契约——约定顺序、支持辅助技术、允许浏览器自动维护编号逻辑。
