<address>标签仅用于标识文档作者或责任方的联系信息，不可泛用于地理地址；其语义专指联系上下文，需配合Schema.org结构化数据满足可访问性与搜索引擎要求，且页面中应限用1–2次、避免嵌套误用。
address 标签只用于联系信息，不是“地址”语义的泛用
<address> 的本意是标识文档或文章作者/所有者的联系信息，不是用来标记任何地理位置或邮寄地址。浏览器不会渲染特殊样式，但辅助技术（如屏幕阅读器）会将其识别为“联系上下文”，影响可访问性语义。
常见误用场景包括：
- 在页脚放公司办公地址（<address> 里写“北京市朝阳区XX路1号”）
- 商品详情页中用它包裹配送地址
- 地图页面中给某个 POI 标注坐标位置
- 正确用法：仅当该信息代表内容创作者、维护者或当前页面责任方的联系方式时才用
<address> - 错误替代方案：地理地址应使用
<p>+itemprop="address"（配合 Schema.org）或<div>+ ARIA 标注 - 注意：一个页面最多出现 1–2 个
<address>，且不应嵌套在<article>外的通用容器里（比如不能放在<header>或<nav>中除非明确属于该区块作者）
address 与 aria-label / contact point 的兼容性差异
单纯用 <address> 不足以满足 WCAG 2.1 或搜索引擎结构化数据要求。它提供的是基础语义，但缺乏机器可解析的意图。
例如，下面这段代码对屏幕阅读器友好，但 Google 富媒体搜索不识别：
<address> Email: <a href="mailto:admin@example.com">admin@example.com</a><br> Tel: +86 10 1234 5678 </address>
- 若需被搜索引擎理解为“联系人”，必须额外添加
itemscope itemtype="https://schema.org/Person"及对应属性（如itemprop="email"） -
<address>内部不宜直接加aria-label—— 它本身已有隐含 role="group"，叠加 aria-label 会造成冗余或冲突 - 真实项目中更推荐组合写法：
<address itemscope itemtype="https://schema.org/Organization">...</address>
address 在现代框架组件中的常见破坏点
React/Vue 组件中容易忽略 <address> 的语义边界。比如把整个页脚封装成 <Footer> 组件后，开发者可能无意识地把版权、备案号、联系信息全塞进一个 <address> 里。
立即学习“前端免费学习笔记（深入）”；
-
<address>不应包含<copyright>（HTML5 中已废弃）、<time datetime>（除非是联系人最后更新时间）或第三方链接（如“关于我们”“隐私政策”） - SSR 渲染时，若服务端生成的
<address>包含动态插入的脚本占位符（如{{contact.email}}），而客户端未及时 hydrate，会导致语义断裂 - Next.js App Router 下，
<address>若出现在layout.tsx中，会被所有子路由复用 —— 这违反“联系信息应归属具体页面作者”的原则
验证 address 是否被正确使用的三个检查点
上线前快速核验：
- 屏幕阅读器读出的内容是否自然表达“这是谁可以联系”（而非“这是哪里”）
- Lighthouse 的 Accessibility Audit 是否报 document.hasAddressElement 且未标记为冗余
- 使用 Chrome DevTools 的 Accessibility Inspector 查看 <address> 节点是否具有 role="group" 和 aria-label="Contact information"（后者由 UA 自动注入，不可手动覆盖）
- 命令行快速检测：
document.querySelectorAll('address').forEach(el => console.log(el.textContent.trim().length > 0))—— 空<address>是常见疏漏 - 避免在 CSS 中重置
address { font-style: normal; }，因为斜体是其默认视觉提示，移除后会削弱语义暗示 - 多语言站点要注意：中文环境下
<address>的语音合成常被误读为“地址”，此时更需依赖 Schema.org 显式标注
真正难的不是写对标签，而是判断“这个信息到底算不算联系人归属”。很多团队卡在这一步，而不是语法层面。
