dfn 标签仅在语义层标记术语定义位置，必须嵌套于规范允许的块级容器（如、）中，优先从title属性提取定义值，仅对首次出现的术语有效，且不依赖视觉样式。
dfn 标签在文档结构中不产生视觉锚点、不自动生成目录项、也不改变 DOM 层级关系——它只在语义层标记“此处是术语的定义位置”，浏览器和辅助技术是否响应，取决于它是否被正确嵌套在可承载定义的上下文中。
dfn 必须出现在能构成「定义上下文」的块级容器里
规范明确限制 dfn 的父元素必须是语义清晰的块级容器，比如 <p></p>、<section></section>、<dt></dt> 或 <figcaption></figcaption>。如果直接塞进 <div> 或 <code><span></span> 里，语义链就断了。
- ✅ 正确：
<p><dfn>DOM</dfn> 是文档对象模型的编程接口。</p> - ❌ 错误：
<div> <dfn>DOM</dfn> 是文档对象模型的编程接口。</div>（<div> 不提供定义语境） <li>❌ 错误：<code><td><dfn>viewport</dfn></td>（表格单元格不是定义容器） - ⚠️ 注意：
<pre class="brush:php;toolbar:false;"></pre>和<code>内禁止嵌套dfn，HTML 规范不允许短语标签作为其子元素 - ✅ 正确：
<dfn title="Document Object Model">DOM</dfn>→ 定义的是 “Document Object Model” - ❌ 危险：
<dfn title="DOM">Document Object Model</dfn>→ 实际定义的是字符串 “DOM”，解释文字被完全忽略 - ❌ 无效：
<dfn title="">fetch()</dfn>→title为空，辅助技术可能跳过该dfn - ⚠️ 注意：内部文本含前后空格或换行（如
<dfn> fetch() </dfn>）会导致提取值变成" fetch() "，影响语义准确性 - ❌ 错误动机：仅为了把某个变量名变斜体就套
dfn，比如<dfn>userAgent</dfn> - ✅ 替代方案：用
<em></em>表达强调，或用<code>表示代码字面量，再配 CSS 控制样式 - ⚠️ 风险：依赖斜体做可访问性提示，等于把语义责任推给视觉表现；当用户关闭样式或使用高对比模式时，
dfn就彻底隐形了 - ✅ 正确流程：首次写
<p>一个 <dfn>URI</dfn> 是统一资源标识符...</p>，后续全部用普通文本URI - ❌ 常见误用：在 API 文档每个参数说明里都给
body加dfn，结果所有body都被识别为“新定义项” - ⚠️ 特殊情况：若同一术语在不同章节含义不同（如 CSS 中的
display在布局 vs 动画上下文），应分别定义，并用id+aria-describedby显式绑定，而非复用dfn
dfn 的术语值提取有严格优先级，title 属性不是“提示”而是定义源
屏幕阅读器和知识抽取工具读取 dfn 所定义的术语时，按固定顺序取值：先看 title 属性，再看子元素的 title，最后才 fallback 到自身文本内容。这个顺序不可跳过，也不能靠 CSS 或 JS 干预。
dfn 不是样式钩子，斜体只是浏览器默认行为
所有主流浏览器对 dfn 应用 font-style: italic，但这只是历史惯例，不是规范要求。一旦项目用了 CSS 重置（比如 dfn { font-style: normal; }），斜体就消失——而语义依然有效。
dfn 只绑定首次出现，重复使用会破坏语义连贯性
dfn 的核心语义是“首次定义”，不是“强调术语”。第二次出现同一术语时加 dfn，会让屏幕阅读器误判为“重新定义”，导致语音播报异常或知识图谱抽取错误。
真正容易被忽略的，是 dfn 的语义有效性完全依赖上下文完整性——它本身不携带解释，也不自动关联段落；只要定义句被拆开、父容器语义模糊、或 title 值与可见文本逻辑错位，这个标签就形同虚设。
