dl 仅适用于存在天然「名→值」映射的内容，如 API 参数、简历技能、产品规格；非术语定义关系（如导航、流程图）应选 table 或 div+ARIA。
直接用 dl 做结构化数据描述是可行的，但必须严格匹配「名-值对」语义，否则会破坏可访问性与搜索引擎解析逻辑——它不是万能容器，而是有明确契约的语义单元。
什么时候该用 dl 而不是 div 或 table
核心判断标准只有一条：内容是否存在天然的「一个名称 → 一个或多个解释/值」映射关系。不是“看起来像两栏”，而是“逻辑上就是术语与定义”。
-
dl合适：API 参数文档（timeout→ 类型、默认值、说明）、简历技能项（React→ 熟练度、项目经验）、产品规格（尺寸→240 × 180 × 45 mm） -
dl不合适：横向导航菜单、步骤流程图、纯图标+文字的工具栏、需要行列对齐的复杂配置表（含多维属性） - 用
table更准：当存在多列维度（如“参数 | 类型 | 必填 | 示例”），且行间存在横向对比关系时 - 用
div+ ARIA 更稳：当 UI 需要高度定制（如折叠面板、标签页内嵌定义），但语义仍是名-值对，此时可保留dl结构，仅用 CSS 控制视觉，而非弃用语义
dt 和 dd 的嵌套边界在哪
嵌套本身合法，但屏幕阅读器对嵌套 dl 的支持有限，超过一层就容易丢失上下文。真正关键的是「谁在读」和「读什么」。
- 允许在
dd内部嵌套完整dl，例如某参数的子字段：<dd><dl><dt>maxRetries</dt><dd>number</dd></dl></dd> - 禁止把
dt或dd放到非dl父容器里，HTML 验证器会报错，读屏器可能跳过或误读 -
dt内不能放p、div、section等块级元素——哪怕只是想加个换行，也会中断语义流；可用br或 CSSwhite-space控制 - 如果某个
dd需要带操作按钮（如“复制值”），按钮必须放在dd内，不能塞进dt——后者只应承载名词性短语
CSS 控制 dl 布局时最常踩的坑
浏览器默认给 dd 加 margin-left 实现缩进，但这在响应式或多列布局中极易错位。靠重置 margin 往往治标不治本。
立即学习“前端免费学习笔记（深入）”；
- 用
display: grid是目前最可靠方案：dl { grid-template-columns: max-content 1fr; }，再配dt { grid-column: 1; }和dd { grid-column: 2; }，避免dt文字过长导致dd换行错列 - 别给
dt设固定宽度——它应由内容自然撑开；设min-width可能导致小屏溢出 -
dd默认无margin-top，若多个dd连续出现，视觉上会挤在一起；建议统一设dd + dd { margin-top: 0.5em; } - 移动端需强制堆叠：用
@media (max-width: 768px) { dl { display: block; } dt, dd { display: block; } }，否则 grid 布局可能撑破视口
结构化数据输出时 dl 对 SEO 和读屏器的真实影响
Google Structured Data Testing Tool 不直接解析 dl，但它会影响页面语义密度和 DOM 可读性——这间接决定富摘要（Rich Snippet）能否被触发，尤其在 FAQ 或 How-to 类型中。
- FAQ 页面中，只要每个
dt是问句（如<dt>如何重置密码？</dt>），对应dd是完整答案，Google 就可能提取为 FAQPage Schema - 读屏器（如 NVDA、VoiceOver）会把
dt读作 “term: xxx”，dd读作 “definition: yyy”，所以dt不能写“点击此处查看说明”，而应写“密码重置链接” - 空
dd或仅含<span></span>会被跳过，但不会报错；而缺失dd的dt会让读屏器失去上下文，比留白更糟 - 如果定义内容含重要链接，确保
a标签在dd内，且链接文本本身具备意义（避免“点击这里”）
最难的部分从来不是写对标签，而是判断某段信息是否真的构成「名-值对」——比如“发布时间：2026-06-15”是，但“用户评论列表”不是。一旦错判，后续所有样式、嵌套、SEO 优化都会在错误前提下徒劳推进。
