dl 标签专用于术语与解释的键值对结构，适用参数说明、词典、FAQ等定义关系场景；误用会导致语义混乱、无障碍失效和 SEO 损害。
dl 标签不是用来做导航菜单或新闻列表的，它专为「术语+解释」这类键值对结构设计。用错场景会导致语义混乱、无障碍访问失效，甚至影响 SEO。
什么时候该用 dl 而不是 ul 或 ol
核心判断标准：内容是否天然成对，且每对存在明确的「名称–描述」关系。
- ✅ 适合：
dl用于参数说明文档（如fetch()的method、headers字段）、词典条目、FAQ 中的问答、API 响应字段释义 - ❌ 不适合：普通导航项（用
ul）、操作步骤（用ol）、产品特性罗列（除非每个特性带独立定义，否则仍是ul） - ⚠️ 注意：
dt和dd必须成对出现，但一个dt可对应多个dd（比如一个术语有多个解释角度），一个dd也可对应多个dt（少见，需谨慎）
dl 的嵌套与可访问性影响
屏幕阅读器会把 dl 识别为“定义列表”，并按 dt→dd 顺序朗读。嵌套不当会打断这个逻辑。
- 嵌套
dl是合法的，但仅限于dd内部（例如某参数的取值说明本身又含子参数）；dt里不能直接嵌dl -
dd中可以放段落、列表甚至表格，但必须确保语义不冲突——比如在dd里再塞一个ul描述该术语的多个用途，没问题；但若把整个 FAQ 列表塞进一个dd，就模糊了层级 - 不要为了视觉缩进而滥用
dl：CSS 的margin或grid更合适，dl的价值在语义，不在样式
常见错误：把 dl 当作“高级 ul”来用
开发者常因 dt 看起来像标题、dd 像内容，就用它渲染配置项列表或用户资料栏——这是典型的语义误用。
- 错误示例：
dl包裹「用户名：张三」「邮箱：zhang@example.com」——这本质是数据展示，不是定义，应改用table或带role="region"的div+aria-label - 正确替代：
dl适合「aria-label：为辅助技术提供元素的可访问名称」这类真正具备定义关系的内容 - 验证方式：删掉所有样式后，纯文本是否仍能清晰表达“X 是什么”？不能，则不该用
dl
dl 的结构推断内容重要性。一旦把非定义内容塞进去，不仅起不到增强作用，反而会稀释关键语义。写之前先问一句——这里真有一个术语需要被定义吗？ 
