食谱步骤必须用而非，因其传达不可变的顺序语义，确保屏幕阅读器正确朗读、键盘导航有序、google富摘要校验通过；必须用包裹每步，禁止直接放文本或等块级元素。
为什么食谱步骤必须用 <ol></ol> 而不是 <ul></ul>
因为步骤有强顺序依赖——“先热锅再倒油”和“先倒油再热锅”结果完全不同。<ol></ol> 不只是显示数字，它向浏览器、屏幕阅读器、搜索引擎明确传达「顺序不可变」的语义。用 <ul></ul> 会导致：语音朗读时跳过编号逻辑、键盘 Tab 流混乱、Google 富摘要校验失败（recipeInstructions 字段要求结构化有序列表）。
<ol></ol> 基础写法与常见错误
必须用 <li> 包裹每一步，且不能省略闭合标签；<ol></ol> 内部不允许直接放文本或 <p></p>。
- ✅ 正确：
<ol> <li>热锅</li> <li>倒油</li> </ol> - ❌ 错误：
<ol>热锅<br>倒油</ol>（无<li>，语义丢失） - ❌ 错误：
<ol> <p>热锅</p> <p>倒油</p> </ol>（<p></p>不是合法子元素） - ⚠️ 注意：
<li>可嵌套其他标签（如<strong></strong>、<em></em>），但不要包裹整段说明文字再加<p></p>
自定义编号格式：type 和 CSS 的分工
type 属性仅适用于 HTML 层级的简单切换（如 type="A" 或 type="i"），但它在现代项目中已逐渐被 CSS 的 list-style-type 取代——后者更灵活、可统一控制，且不影响微数据解析。
- HTML 层建议保持默认：
<ol></ol>不加type，让语义干净 - 如需大写字母编号，优先用 CSS：
ol { list-style-type: upper-alpha; } - 避免混用：
<ol type="I"></ol>+list-style-type: lower-roman会冲突，浏览器行为不一致 - 特殊场景（如跨步编号）才用
value属性：<li value="5">第五步</li>，但仅限<ol></ol>中的<li>
与 Schema.org 微数据配合的关键点
要让 Google 识别为食谱富摘要，recipeInstructions 必须包裹一个有效的 <ol></ol> 结构，且每个 <li> 内容需为纯文本或内联元素（不能含块级标签如 <div>、<code><p></p>）。
- ✅ 合规：
<div itemprop="recipeInstructions"><ol> <li>热锅至冒烟</li> <li>下蒜末</li> </ol></div> - ❌ 失效：
<div itemprop="recipeInstructions"><ol><li><p>热锅至冒烟</p></li></ol></div>（<p></p>是块级，破坏字段值提取） - ⚠️ 容易忽略：
<ol></ol>必须直接子元素为<li>，中间不能插入注释、空格文本节点（尤其 JS 动态生成时易多出换行）
