dfn 标签仅用于页面中首次出现且明确给出定义的术语，必须包含定义内容而非仅包裹术语，滥用会干扰辅助技术；其默认样式弱，需 CSS 强化视觉提示，且不可替代 abbr 或 code 的语义用途。
dfn 标签只用于首次定义术语，不是所有术语都该套它
dfn 的语义很窄：它只应在页面中**第一次出现且明确给出定义**的术语处使用。比如 <dfn>HTTP</code> 后紧跟着“超文本传输协议”，才算合规。如果只是重复提到“HTTP”，或只是强调、加粗，用 <code>strong 或 CSS 更合适。滥用 dfn 会干扰屏幕阅读器判断——它会把每个 dfn 当作新定义播报，导致用户困惑。
必须配合实际定义内容，不能光包个词
单独写 <dfn>API</dfn> 是无效的。W3C 明确要求 dfn 元素的内容**就是该术语的定义本身**，或至少是定义的核心部分。常见正确写法：
<p>我们使用 <dfn>REST</dfn>（Representational State Transfer）架构风格设计接口。</p>
或者更严谨地把定义拉出来：
<p><dfn>DOM</dfn> 是文档对象模型（Document Object Model）的缩写，它将 HTML 文档表示为节点树。</p>
注意：dfn 里不要塞链接、图片或嵌套其他语义标签（如 code），除非定义本身需要——比如定义里包含代码示例，那 code 是允许的，但要确保主干仍是自然语言定义。
立即学习“前端免费学习笔记（深入）”；
浏览器默认样式弱，别依赖它视觉提示
多数浏览器对 dfn 只做斜体渲染（font-style: italic），而且不加下划线、无 hover 效果、不带 tooltip。这意味着用户根本看不出哪句是定义、哪句是普通术语。如果你需要视觉强化：
- 用 CSS 显式设置
dfn { font-style: italic; border-bottom: 1px dotted #666; } - 加
title属性仅作补充（如<dfn title="Application Programming Interface">API</dfn>），但别把它当主要定义手段——title不被所有辅助技术读取，且移动端基本不可见 - 避免用 JS 动态插入定义弹窗，这破坏语义流，也绕过
dfn的本意
和 abbr、code 混用时要注意语义优先级
遇到像 “JSON” 这类既是缩写又是术语的词，得按上下文选标签：
- 首次定义它时：用
<dfn>JSON</dfn>+ 后续说明“JavaScript Object Notation”，这是定义行为 - 之后提及时：用
<abbr title="JavaScript Object Notation">JSON</abbr>，这是缩写解释 - 代码上下文中：直接用
<code>JSON.parse()</code>，不套dfn——函数名不是术语定义
嵌套顺序也有讲究：如果定义里含代码，dfn 应包裹整个定义句，code 放在句内，例如：<dfn><code>fetch()</code></dfn> 表示“fetch() 函数”这个整体是被定义的术语，而不是只定义 fetch() 这个字符串。
真正难的是判断“这里算不算首次定义”——它取决于整篇文档的逻辑起点，不是按字面出现顺序，而是按读者认知路径。这点没标准答案，得靠人读一遍再决定。
