必须标记首次出现且读者可能不熟悉的技术或专业缩写，如api、dom、http、w3c；而html、css、mr.、dr.及自造未定义缩写不应滥用abbr。
哪些缩写词必须用 abbr 标记
不是所有缩写都值得套 abbr。真正该标记的，是那些「首次出现 + 读者可能不熟悉」的技术或专业缩写。比如在一篇面向初学者的前端文档里，API、DOM、HTTP、W3C 这类词就属于典型场景——它们不是日常词汇，且上下文没提前解释过。
常见误判点：
- 把
HTML、CSS当成必须标：除非文档目标读者是完全零基础（如小学生科普页），否则重复加abbr反而干扰语义和可读性 - 给
Mr.、Dr.加abbr：这些已是通用敬称，浏览器和屏幕阅读器已有内置处理，加了反而冗余 - 对自造缩写（如文档里突然冒出
UXF却没定义）强行套abbr：这等于把错误包装成“已解释”，比不标更误导
abbr 的 title 属性怎么写才有效
abbr 本身不输出任何内容，全靠 title 属性承载语义。这个值不是备注，而是必须严格对应缩写的完整展开形式。
正确做法：
-
title值只写全称，不加括号、不加说明文字。例如：<abbr title="Application Programming Interface">API</abbr>✅；<abbr title="API (Application Programming Interface)">API</abbr>❌ - 优先用英文全称（因多数缩写源于英文），中文场景下若需中文展开，要确保语法自然、屏幕阅读器能顺畅朗读，比如
title="超文本传输协议"比title="HTTP协议"更准确 - 同一个缩写在页面中只在首次出现时加
abbr，后续直接写API即可——重复标记不会增强语义，反而增加 DOM 负担
移动端和辅助技术下 abbr 是否有用
悬停提示（hover tooltip）在手机上确实无效，但这不代表 abbr 在移动端没意义。
真实情况：
- 屏幕阅读器（如 VoiceOver、NVDA）会主动读出
title内容，只要abbr存在且title正确，语义就生效 - 部分触屏设备支持长按触发
title提示，虽非标准行为，但有兼容性红利 - 搜索引擎会抓取
title值来强化上下文理解，这对 SEO 是隐性收益 - 纯靠 CSS hover 效果（如下划线）无法替代
title——视觉提示只是辅助，语义才是核心
和 dfn 搭配使用时要注意什么
当一个术语本身含缩写（比如“语义化 HTML”），或需要先定义再缩写（如“响应式设计（Responsive Design, RD）”），dfn 和 abbr 可以嵌套，但顺序不能错。
关键约束：
-
abbr可以放在dfn内部，例如：<dfn><abbr title="HyperText Markup Language">HTML</abbr></dfn> - 反过来不行：
<abbr><dfn>HTML</dfn></abbr>语义混乱，dfn必须直接包裹被定义的术语本身 - 如果缩写本身就是术语（如 “CSS” 表示层叠样式表），应优先用
dfn包裹，并在句中自然带出定义，而非仅靠title：“<dfn>CSS</dfn> 是一种用于描述 HTML 文档样式的语言。”
最易被忽略的细节：很多人以为加了 abbr 就算完成语义标注，其实它只解决“缩写是什么”，不解决“这个词为什么重要”——后者得靠 dfn 或上下文句子来承载。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
