嵌套列表必须严格在li内部，否则计数器错乱；子ol/ul未包在父li中会被视为新列表，导致编号重置为a.而非b.；验证需检查dom中子ol是否为父li的直接子节点。
嵌套必须严格在 li 内部，否则计数器全乱
浏览器对嵌套列表的编号重置行为，根源在于 DOM 结构是否合法。只要子 ol 或 ul 没被包在父级 li 里，它就被视为全新列表——A. 后面永远是另一个 A.，而不是 B.。
- 错误写法：
<ol type="A"></ol> <ol type="A"></ol>（两个兄弟列表） - 正确写法：
<ol type="A"><li>A. Item<ol type="1"><li>1. Sub</li></ol> </li></ol> - 验证方式：用浏览器开发者工具检查子
ol是否是父li的直接子节点，不是则语义断裂
list-style-type 只控制符号，不控制计数逻辑
设 type="a" 或 type="1" 只改显示样式，不会让第二层“接着第一层编号”。比如 A. 下的 1.，永远从 1 开始，哪怕上一章已到第 5 条。
- 想实现「1.2.1」这类连续编号，必须用 CSS
counter-reset/counter-increment+::before -
type属性在 IE9+ 和所有现代浏览器都支持，但counter-系列在 IE11 及更早版本中部分失效 - 移动端无需担心兼容性，但若需支持旧版企业内网系统，建议 fallback 到纯
type方案
缩进异常不是 bug，是 padding-left 累加的结果
嵌套越深，列表越靠右？这不是 HTML 错了，而是浏览器默认给每个 ul/ol 设了 padding-left: 40px，每嵌一层就叠加一次。
- 最简修复：
ol ol, ul ul { margin-left: 0; padding-left: 20px; } - 别用
text-indent：它只缩进首行，多行列表项会错位 - 如果用了
normalize.css或其他 reset，先查它是否已覆盖了ul, ol的padding
超过三层嵌套时，语义和可访问性会快速劣化
结构上允许无限嵌套，但屏幕阅读器对 >3 层的播报容易混乱，键盘用户用 ArrowDown 也容易跳过中间层级。
- 医疗文档或法律条文等强结构场景，建议用 CSS counter 实现「A.1.a」但限制 DOM 层级为 3 层
- 导航类树形菜单，优先走
role="tree"+role="treeitem"路线，而非靠ol堆叠 - 每个
li必须有非空文本内容，空li会导致辅助技术跳过整段结构
ol 套 ol 表示步骤中的子步骤没问题，但用它表达「分类 > 子类 > 标签」就违背了有序列表的本意——这时候该换 ul 或直接上 nav。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
