必须用<ol>而非<ul>写目录，因目录天然有序、章节编号不可互换；<ol>提供语义顺序、屏幕阅读器正确播报、SEO结构化识别，并支持start、type等原生控制。
ol 是唯一语义正确、可访问、可打印、被搜索引擎识别的目录容器，用 ul 模拟编号只是视觉假象，会直接破坏屏幕阅读器播报、SEO 结构化数据提取和键盘导航。
为什么必须用 ol 而不是 ul 写目录
目录天然具有不可交换的顺序：第 2 章永远在第 1 章之后，附录 A.1 必须先于 A.2。浏览器和辅助技术依赖 ol 的语义推断这种层级关系。
-
ul只表示“一组无序项目”，读屏软件会读作“列表项一、列表项二”，而非“第二章、3.2 节” - 搜索引擎无法从
ul+ CSS 伪元素生成的数字中识别真实章节结构，ol则能参与结构化数据（如 BreadcrumbList） - 打印时，
ul+::before { content: "1. " }极易因分页或 UA 样式失效，而ol的原生编号稳定可靠 -
ol支持start和type属性，比如跳过前两章直接从<ol start="3">开始，ul完全做不到
ol 嵌套写法：二级目录怎么不乱
子级 ol 必须完整写在父级 li 内部，不能并列放在同层 body 或 nav 中——这是最常被忽略的嵌套规则。
- ✅ 正确：
<li>第二章：DOM 操作<ol><li>2.1 事件绑定</li></ol></li> - ❌ 错误：
<li>第二章：DOM 操作</li><ol><li>2.1 事件绑定</li></ol>（子ol脱离父li，语义断裂） - 超过三层嵌套（如 2.1.1.1）会让缩进失控，建议用 CSS 控制
margin-left替代依赖 UA 默认缩进 - 若某节内罗列 API 名称等无序内容，可在该
li内用ul，外层仍保持ol语义
锚点链接与 ID 匹配的硬性要求
目录项点击后能否准确定位，取决于 a[href] 与目标标题 id 是否严格一致：大小写、连字符、无空格、无中文。
立即学习“前端免费学习笔记（深入）”；
- 标题写成
<h2 id="event-handling">事件处理</h2>，目录就必须是<a href="#event-handling">事件处理</a> - ID 中出现空格或中文（如
id="事件处理"）会导致a[href="#事件处理"]失效，浏览器解析为非法 fragment - 避免给所有标题加 class 后手动维护链接，应让每个
h2~h4自动生成小写连字符 ID（可通过脚本或构建工具实现） - 配合
scroll-margin-top补偿固定头部遮挡，否则点击后标题会被顶到视口顶部之下
真正难的不是写出 ol，而是让每层嵌套都落在正确的 li 里、每个 href 都精准指向一个真实存在的小写连字符 id、每个子 ol 都保有它自己的 start 和 type 逻辑——这些细节一旦出错，目录就从“可用”退化为“看起来像目录”。
