有序列表的执行顺序由的dom书写顺序决定，而非reversed、start或value属性；这些仅影响显示编号，不改变实际逻辑顺序；动态数据需先排序再渲染。
有序列表的默认行为是数字编号，但执行顺序得靠人工排布
HTML 的 <ol></ol> 本身不记录或控制“执行逻辑”，它只是按子元素 <li> 的书写顺序渲染序号。所谓“执行顺序”，实际是你把步骤按真实运行先后写进 DOM 的结果。
常见错误是以为加了 reversed 或改 start 就能改变执行流——其实那只是显示效果，和代码执行无关。
- 想表达“先做 A，再做 B，最后做 C”，就把
<li>A</li> <li>B</li> <li>C</li>按这个顺序放进<ol></ol> - 若后端返回的是乱序步骤（比如带
step_order: 2字段），前端必须先排序再生成<li>，不能依赖value属性“修正”顺序 -
value属性只影响单个<li>的显示编号，不影响后续项的自动递增逻辑，容易导致序号断裂
用 start 和 reversed 调整起始值或倒序显示
这两个属性只改视觉编号，适合文档分段或回溯说明场景，比如调试日志从第 5 步开始列，或展示“撤销操作”的逆向步骤。
例如：
<ol start="5"> <li>检查缓存状态</li> <li>发起网络请求</li> </ol>
会显示为 “5. 检查缓存状态”、“6. 发起网络请求”。reversed 则让编号从大到小，但 <li> 的 DOM 顺序仍决定内容呈现次序。
-
start接整数，负数也合法（如start="-2"→ -2, -1, 0…） -
reversed是布尔属性，写上即生效，无需赋值 - 二者同时使用时，
start指定的是第一个<li>的显示值，之后递减
避免用 value 属性强行“跳号”，它破坏可维护性
有人为模拟“跳过某步”，在某个 <li> 上写 value="10"，结果后续 <li> 编号变成 11、12——这会让协作同事看不懂结构，也难用 CSS 选中“第 n 步”。
- 真正需要跳步（如“步骤 3 暂不启用”），应直接省略该
<li>，而不是留空 +value - 需要强调某步是分支（如“若超时则执行步骤 3a”），用嵌套
<ol></ol>更清晰 - 所有靠
value实现的编号逻辑，都建议移到 JS 渲染层统一处理，HTML 只保留语义顺序
当步骤来自异步数据，别在模板里硬写 <ol></ol>
如果步骤列表由 API 返回且字段含 order、depends_on 等依赖信息，直接用 <ol></ol> 套循环很可能出错——比如后端返回顺序错乱，或前端没做拓扑排序。
这时候的关键动作是：拿到数据后，先用 JS 按依赖关系或 order 字段排序，再生成 <li>。否则用户看到的“执行顺序”只是请求返回的顺序，不是真实逻辑顺序。
- 简单排序可用
arr.sort((a, b) => a.order - b.order) - 有复杂依赖（如 A 必须在 B 后）就需构建 DAG 并拓扑排序，不能只靠
order字段 - 服务端已保证顺序？仍建议前端校验并 log 警告，因为网络或缓存可能让响应错乱
实际写的时候，最容易被忽略的是：DOM 顺序 ≠ 执行逻辑顺序。尤其在动态渲染、条件步骤、错误恢复路径等场景，光靠 <ol></ol> 标签无法自证正确性，得靠数据结构和排序逻辑兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
