该用 ul 而不是 ol 时：列表项可任意调换顺序而不影响理解，如导航菜单、标签云；ol 则用于有逻辑顺序的场景，如操作步骤、法律条款，其编号承载语义而非装饰。
什么时候该用 ul 而不是 ol
无序列表 ul 的核心语义是“项目之间没有先后、主次或依赖关系”。一旦你发现列表项可以任意调换顺序而不影响理解，就该用 ul。
常见误用：把导航菜单写成 ol，只因为想让它显示数字；或者把商品特性列表硬套 ol 只为“看起来更正式”。这会误导屏幕阅读器和搜索引擎——它们会认为这些项存在逻辑流程或优先级。
-
ul内部只能直接包含li，不能塞p、div或其他块级元素（除非包裹在li里） - 导航菜单、标签云、功能图标列表、相关文章推荐，都属于典型
ul场景 - 如果需要视觉上“去编号”，别删标签，而是用 CSS 控制：
list-style: none
ol 的编号不是装饰，它承载流程语义
ol 不只是“带数字的 ul”。浏览器和辅助技术会把它当作一个有内在顺序的结构单元。比如操作步骤、法律条款编号、考试答题顺序——换位置就可能改变含义。
容易踩的坑：手动写 <p>1. 打开电源</p><p>2. 按启动键</p>。这样既没语义，也无法用 CSS 统一控制编号样式，更无法被屏幕阅读器识别为“第1步”“第2步”。
立即学习“前端免费学习笔记（深入）”；
- 必须用
li包裹每一条，不能用p或div替代 - 跨多级流程时，子步骤应嵌套在父
li内部的ol中，而不是新建一个并列ol -
start属性可指定起始编号（如start="3"），但不要用它“跳号”来掩盖结构混乱
dl 不是“用来凑数”的冷门标签
很多人把 dl 当作“不那么重要的列表”，只在写词汇表时才想起来。其实只要内容是“名词+解释”配对关系，dl 就比 ul 或表格更准确——比如商品参数、API 接口字段说明、FAQ 条目。
典型错误：用两个并列 ul 分别列“属性名”和“描述”，或用表格强行模拟，结果语义断裂、无障碍支持差。
-
dt必须紧跟在dl后，且每个dt后应有至少一个dd - 一个
dt可对应多个dd（如一个术语有多个释义），一个dd也可对应多个dt（如多个同义词指向同一解释） - 不要把
dl当作布局工具——它不负责对齐，对齐靠 CSS；它的价值在于让机器知道“这个是术语，那个是定义”
嵌套层级错位会导致大纲崩坏
浏览器根据 HTML 标签生成文档大纲（outline），供屏幕阅读器导航和 SEO 解析。而 ul/ol 嵌套如果脱离 li 上下文，就会让大纲“断层”——比如在 ol 外直接写 ol，或把子列表提到父 li 外面。
最常被忽略的一点：嵌套的 ol 或 ul 必须完整包裹在上一级 li 内部，否则语义链就断了。CSS 可能还能渲染出类似效果，但机器读不到结构。
- 检查方式：用浏览器开发者工具的“Accessibility”面板看大纲树，或用在线工具（如 WAVE）验证
- 多级编号（如 1.1、1.2）不能靠手写，而要靠嵌套 +
type属性（如<ol type="a">）配合 CSS counter 实现 - 如果某条
li内容太长，需分段落，用p包裹文字即可，不要为了“换行”而拆出额外列表
