ol 必须嵌套在 li 内部，否则浏览器会自动闭合前一个 ol 并新建，导致编号重置、语义断裂、屏幕阅读器误读；各层级 type 应按 a→1→a→i 惯例匹配；避免 css 重置破坏缩进；动态生成时需确保结构合法。
ol 嵌套必须写在 li 里，否则编号会重置、语义断裂、屏幕阅读器读错层级。
为什么 ol 必须嵌套在 li 内部
浏览器只认「li 包含另一个 ol」为合法子层级。若把子 ol 放在 li 外面（比如紧挨着 li 并列），HTML 解析器会自动闭合前一个 ol，新开一个——导致第二级编号从 A. 重新开始，而非延续第一级的 B. 下的子项。
常见错误现象：
- 第二级列表总是显示 A.、B.、C.，哪怕父项是 B. 或 C.
- 用键盘 Tab 导航时，焦点跳过整个子列表
- Chrome DevTools 的 Accessibility 面板显示“listitem has no list parent”
type 属性在各层级的实际取值规则
每层 ol 的 type 独立生效，但必须与语义匹配。不是所有组合都合理，比如 type="i"（小写罗马数字）放在第三级后接 type="1" 就容易混淆。
推荐搭配（按文档惯例）：
- 一级：
type="A"（如 A. HIV infections） - 二级：
type="1"（默认，如 1. Code only confirmed cases） - 三级：
type="a"（如 a. That player may pass any balls…） - 四级：
type="i"（如 i. first subpoint）——但极少需要四层，慎用
注意：type 是 HTML 属性，不是 CSS；它影响的是语义和默认渲染，不替代 list-style-type。
如何避免嵌套后缩进错乱或内容溢出
默认情况下，浏览器对嵌套 ol 有基础缩进，但一旦加了自定义 CSS（比如重置 margin 或用了 display: flex），就极易破坏视觉层级。
实操建议：
- 不要全局重置
ol, ul { margin: 0; }，至少保留ol ol, ul ul的缩进 - 用
padding-left替代margin-left控制缩进，避免外边距塌陷干扰 - 若需精确对齐（如法规文本中编号与文字左缘对齐），给
li设list-style-position: inside，再配合text-indent - 移动端务必测试：某些 Safari 版本对深层嵌套的
type渲染不一致，可加counter-reset回退
动态生成多级 ol 时最容易漏掉的点
服务端模板（如 Jinja、EJS）或前端 JS 拼接时，开发者常只关注数据循环，忽略 HTML 结构合法性。
关键检查项：
- 每个子
ol是否严格位于上一层的li开始标签和结束标签之间 - 是否误把
ol插入到p、div或空行中（这些都会触发浏览器自动闭合） - 是否存在未闭合的
li（尤其在条件渲染分支里） - 如果用了
start属性，确认它只出现在最外层ol，子层勿重复设置
复杂层级下，靠肉眼检查 HTML 源码几乎不可靠；上线前用 Lighthouse 的「Accessibility」审计或手动运行 document.querySelectorAll('ol li ol') 验证嵌套路径是否完整。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
