dfn 的术语判定严格按优先级执行：先取 title 属性值，再取子元素的 title，最后取纯文本内容；任一匹配即终止，不回退。
dfn 标签本身不定义术语含义，它只标记“此处是术语首次出现/需被定义的位置”；真正决定“被定义的是什么”的，是 title 属性值、子元素的 title，或其直接文本内容——顺序严格按规范执行，不能靠猜。
dfn 的术语判定规则必须按优先级逐条匹配
浏览器和辅助技术（如屏幕阅读器）解析 dfn 时，会严格按以下顺序确定“被定义的术语”：
- 如果
dfn元素有title属性，则该属性值就是术语（例如<dfn title="Cascading Style Sheets">CSS</dfn>→ 术语是 "Cascading Style Sheets"） - 否则，若
dfn只包含一个子元素（如abbr或span），且该子元素有title属性，则取子元素的title值 - 否则，
dfn的纯文本内容就是术语（例如<dfn>HTML</dfn>→ 术语是 "HTML"）
注意：中间任何一步命中即终止，不会 fallback 到下一步。比如 <dfn title="">HTML</dfn> 中 title 存在但为空，术语仍是空字符串，不是 "HTML"。
title 属性不是可选装饰，而是语义核心
很多开发者把 title 当成 tooltip 提示用，但在 dfn 中它是语义锚点——影响 ARIA 解析、搜索引擎术语抽取、文档索引生成等实际链路。
立即学习“前端免费学习笔记（深入）”；
- 不写
title时，dfn仅靠文本内容提供术语，无法表达“全称/解释性名称”，比如缩略词WHO必须配title="World Health Organization"才算完整定义 - 写了
title却没在父句中给出解释（如<p><dfn title="fetch API">fetch</dfn> 是...</p>），会导致术语与定义脱节，破坏可访问性 -
title值不应重复dfn内文本（如<dfn title="HTML">HTML</dfn>），这等于没提供额外信息，违背使用初衷
常见误用：嵌套、滥用、与 abbr 混淆
dfn 不是视觉样式标签，也不是通用强调工具，错误用法会削弱语义有效性：
- 嵌套
dfn（如<dfn><dfn>term</dfn></dfn>）无效，外层dfn的title会被忽略，内层才起作用 - 用
dfn包裹整段定义（如<dfn><p>A markup language...</p></dfn>）违反内容模型——dfn是内联元素，不允许块级子元素 - 把
dfn当abbr用（如<dfn title="JavaScript">JS</dfn>）逻辑错位：abbr表示“缩写”，dfn表示“首次定义”，二者语义不同，不可互换
实际部署建议：最小化 + 显式定义句
真正起效的 dfn 必须出现在一句完整定义中，且术语本身要清晰可定位：
- 优先用
title属性提供全称或标准释义，文本内容保持简洁（如缩略词、代号） - 确保父
p或最近的定义性上下文（如dd、section）明确解释该术语，否则只是挂了个“定义”标签，没定义内容 - 避免在同一页多次用
dfn定义同一术语；如需复述，用abbr或普通文本引用即可 - 检查输出 HTML 时是否意外删掉了
title属性（常见于 CMS 模板或富文本编辑器过滤）
最易被忽略的一点：术语判定完全依赖属性存在性，而非内容长度或上下文智能——哪怕你写了十行解释，只要 dfn 没 title 且文本是单个词，那它就只定义那个词，不多也不少。
