ol必须只包含li元素，不能直接放文本或div；浏览器会忽略hello中的纯文本，编号不显示且不报错；常见错误是将p或div直接嵌入ol，正确结构须用li包裹每个条目。
ol 必须只包含 li，不能直接放文本或 div
浏览器会忽略 <ol>Hello</ol> 里的纯文本，编号不出现，也不报错。常见错误是把 <p></p> 或 <div> 直接塞进 <code><ol></ol> ——HTML 规范只允许 <li>（以及 <script></script>、<template></template> 等极少数例外）作为直接子元素。
正确写法是每个条目必须用 <li> 包裹：
<ol> <li>第一步：准备材料</li> <li>第二步：开始制作</li> <li>第三步：完成测试</li> </ol>
- 若需在
<li>内放段落、标题或容器，完全合法：<li><p>带格式的说明</p></li> - 但
<ol><p>错！</p></ol>这种结构会被解析为“空列表 + 外部孤立<p></p>”，编号丢失且语义断裂 - Vue/React 模板中漏写
嵌套有序列表必须严格放在 li 里面
想实现 A. → 1. → a. 这类多级编号，子 <ol></ol> 必须作为父级 <li> 的**直接内容**，而不是跟在 后面并列写。
错误写法（断开嵌套，浏览器重置计数）：
<ol type="A"> <li>A. First item</li> </ol><ol type="1"> <!-- ❌ 独立新列表 --><li>1. Sub-item</li> </ol>
正确写法（子列表嵌在 <li> 内）：
<ol type="A">
<li>A. First item
<ol type="1">
<li>1. Sub-item
<ol type="a">
<li>a. Detail</li>
</ol>
</li>
</ol>
</li>
<li>B. Second item</li>
</ol>
- 层级错位会导致第二级始终从 1. 开始，而非延续前序逻辑
- 屏幕阅读器依赖这种嵌套关系播报层级，断开即语义失效
- W3C Validator 会警告“
<ol></ol>not allowed as child of<ol></ol>”，除非它在<li>里
start 和 type 属性的兼容性与限制
start 和 type 是 HTML 原生属性，但有明确边界：它们只控制视觉编号，不改变 DOM 顺序或可访问性语义。
-
start值必须为整数，start="-2"或start="3.5"都退化为start="1" - IE11 及更早版本不支持
start，始终从 1 开始 -
type仅支持有限值："1"、"a"、"A"、"i"、"I"；lower-greek等 CSS 值在type上无效 - 若需跨章节连续编号（如 A. → B. → C. 不中断），
start无法满足，得靠 CSScounter-reset/counter-increment手动维护
用 CSS 控制样式比依赖 HTML 属性更可靠
现代项目中，list-style-type 和伪元素比 type 属性灵活得多，尤其当需要统一设计语言或响应式适配时。
- 用
list-style: none清除默认符号后，配合::before+content插入自定义编号或图标 -
list-style-position: inside会让换行文字对齐缩进，outside（默认）保持项目符号左对齐固定位置 - 给
<ol></ol>设display: flex会导致编号消失——因为list-style在 flex 容器下不触发，必须给每个<li>单独设置 - 避免混用：
<ol type="a"></ol>+list-style-type: upper-roman会产生冲突，优先以 CSS 为准
嵌套合法性、属性边界、CSS 替代路径——这三点最容易被跳过，但恰恰决定列表能否在真实环境里稳定输出预期结构和语义。
