子ol必须是li的直接子节点，否则浏览器会将其移至外层同级；用document.queryselectorall('ol > li > ol')可验证合法嵌套，非空结果说明结构非法。
用 document.querySelectorAll('ol li ol') 检查子列表是否在 li 内部
浏览器对 ol 嵌套的合法性判断非常严格：子 ol 必须是父级 li 的直接子节点，否则会被视为全新列表，编号重置为 A. 而非 B.。你写的 <ol>
<li>A.</li>
<ol><li>1.</li></ol>
</ol> 实际解析后，第二个 ol 会“跳”到外层 ol 同级，变成两个并列列表。
运行以下查询能立刻暴露问题：
-
document.querySelectorAll('ol ol')→ 如果返回非空结果，说明子ol不在li里，结构非法 -
document.querySelectorAll('ol > li > ol')→ 应该覆盖所有合法嵌套；若数量明显少于视觉上的“缩进列表”，说明有漏包 -
[...document.querySelectorAll('ol')].forEach(ol => console.log(ol.outerHTML.slice(0, 80)))→ 快速扫一遍源码中ol出现的位置，看是否紧贴li开始
在 Elements 面板里确认 ol 是否被浏览器“踢出”li
别信源码缩进，信真实 DOM 结构。打开 Chrome DevTools → Elements → 找到一个看起来是“二级列表”的 ol，点击展开它的父节点。如果它不在某个 li 的子节点列表中，而是和那个 li 并列（同级、缩进相同），那就是已被浏览器自动修复过的真实证据。
常见视觉陷阱：
- 你在源码里写了
<li>主项</li> <ol><li>子项</li></ol>→ Elements 里看到的是两个兄弟节点，不是嵌套 - 用了注释或换行干扰解析：
<li>主项</li> <!-- 注释 --><ol></ol>→ 某些解析器可能提前闭合li -
ol标签写在了li的开始标签之后、但文本内容之前，比如<li> <ol><li>...</li></ol>文字</li>→ 文字会被移到li外，破坏语义
W3C Validator 能准确定位到哪一行哪一列
复制出错的 HTML 片段（包括外层容器），粘贴到 validator.w3.org。它不会只说“嵌套错误”，而是明确标出：
- “
Element ol not allowed as child of element ol in this context” —— 表示子ol直接挂在父ol下，缺了li - “
Start tag li omitted, but its declaration does not permit omission” —— 表示浏览器自动补了li，但原始代码没写，结构不可靠 - 如果用了
type="1"或start="5"却没生效，Validator 通常会连带指出父级缺失导致的上下文丢失
这个验证不依赖渲染，是纯语法+语义校验，比肉眼或 DOM 查询更早发现问题源头。
检查 CSS 缩进是否掩盖了结构断裂
很多人以为“看起来缩进了就是嵌套对了”，但 ol ol { padding-left: 20px } 这类样式会让非法嵌套也视觉上对齐。结果是：DOM 断裂、编号重置、屏幕阅读器播报错乱，而你还在调 margin。
真正要确认结构是否成立，得关掉所有自定义样式：
- 在 Elements 面板右键目标
ol→ “Force element state” → 勾选:not(*)（快速清空所有 CSS） - 或者临时禁用 Styles 面板里所有规则，只留浏览器默认样式
- 此时如果子
ol突然跑到主列表外、编号从 A. 变回 A. 而非 B.，基本可以断定嵌套未落在li内
最易被忽略的一点：嵌套层级本身没问题，但某一层的 li 是空的（比如只有 <li>），会导致后续所有子 ol 失去合法父容器——这种空节点在 Elements 面板里极难发现，必须用 document.querySelectorAll('li:empty') 主动揪出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
