HTML结构中DL/DT/DD定义列表在结构化数据描述中的高级应用技巧-html教程-PHP中文网

dl 仅适用于存在天然「名→值」映射的内容，如 api 参数、简历技能、产品规格；非术语定义关系（如导航、流程图）应选 table 或 div+aria。

html结构中dl/dt/dd定义列表在结构化数据描述中的高级应用技巧

直接用 dl 做结构化数据描述是可行的，但必须严格匹配「名-值对」语义，否则会破坏可访问性与搜索引擎解析逻辑——它不是万能容器，而是有明确契约的语义单元。

核心判断标准只有一条：内容是否存在天然的「一个名称 → 一个或多个解释/值」映射关系。不是“看起来像两栏”，而是“逻辑上就是术语与定义”。

dl 合适：API 参数文档（timeout → 类型、默认值、说明）、简历技能项（React → 熟练度、项目经验）、产品规格（尺寸 → 240 × 180 × 45 mm）
dl 不合适：横向导航菜单、步骤流程图、纯图标+文字的工具栏、需要行列对齐的复杂配置表（含多维属性）
用 table 更准：当存在多列维度（如“参数 | 类型 | 必填 | 示例”），且行间存在横向对比关系时
用 div + ARIA 更稳：当 UI 需要高度定制（如折叠面板、标签页内嵌定义），但语义仍是名-值对，此时可保留 dl 结构，仅用 CSS 控制视觉，而非弃用语义

嵌套本身合法，但屏幕阅读器对嵌套 dl 的支持有限，超过一层就容易丢失上下文。真正关键的是「谁在读」和「读什么」。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

允许在 dd 内部嵌套完整 dl，例如某参数的子字段：<dd><dl> <dt>maxRetries</dt> <dd>number</dd> </dl></dd>
禁止把 dt 或 dd 放到非 dl 父容器里，HTML 验证器会报错，读屏器可能跳过或误读
dt 内不能放 p、div、section 等块级元素——哪怕只是想加个换行，也会中断语义流；可用 br 或 CSS white-space 控制
如果某个 dd 需要带操作按钮（如“复制值”），按钮必须放在 dd 内，不能塞进 dt ——后者只应承载名词性短语

浏览器默认给 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 布局可能撑破视口

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 内，且链接文本本身具备意义（避免“点击这里”）