<address> 标签仅在 <body> 或 <article> 的直接子元素中生效，语义绑定严格；内容限于 phrasing content，现代浏览器已移除默认样式，SEO 不识别该标签，须配合 JSON-LD 实现富摘要。
address 标签只在 body 或 article 直接子元素中生效
它不是“放联系信息的通用容器”，而是语义绑定型标签：只有作为 <body> 或 <article> 的**直接子元素**时，浏览器和屏幕阅读器才会识别其责任归属含义。嵌套在 <div>、<section>、<header> 甚至 <main> 里，<address> 就退化为普通块级元素，语义完全丢失。
常见误用包括：
- 把转载文章的原作者邮箱塞进自己页面的
<body>底部<address>—— 这等于向辅助技术谎称“该页面由他人维护” - 在博客列表页的每篇文章卡片里，把
<address>放在<div class="card">内部 —— 父容器不是 sectioning root，语义不触发 - 同一页面多个
<address>都放在<body>下 —— 浏览器通常只识别第一个，其余被当作普通文本渲染
address 内容只能是 phrasing content
HTML5 明确限制 <address> 只能包含短语级内容（phrasing content），即内联元素或纯文本，不能出现任何块级结构。写错会触发浏览器自动修复（如闭合意外开启的 <p>），结果不可控，且无法通过 W3C HTML 验证。
允许的内容有：
立即学习“前端免费学习笔记（深入）”；
-
<a href="mailto:me@example.com">me@example.com</a>（必须带mailto:或tel:协议） -
<strong>张三</strong>（强调责任人姓名） -
<br>（用于换行分隔不同联系项） - 纯文本，如 “办公地址：北京市朝阳区XX路1号”（但需确保这是责任人真实归属地）
禁止的内容有：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<p>、<div>、<h3>、<ul>—— 这些会导致验证失败，部分读屏器跳过解析 - 空
<address></address>或仅含空格/图标 —— JAWS 等旧版读屏器可能直接忽略 - 版权符号 ©、发布日期、文档标题等元数据 —— 它们不属于联系信息范畴
现代浏览器已移除默认斜体样式，别靠视觉判断是否生效
Chrome 120+、Firefox 125+ 已彻底移除 <address> 的 font-style: italic、默认 margin 和换行行为。它现在视觉上和 <div> 几乎一致 —— 这不是 bug，是标准演进：语义和样式必须解耦。
正确做法是：
- 显式重置并增强视觉提示：
address { font-style: normal; padding-left: 1em; border-left: 2px solid #ccc; } - 避免写
address { display: block; }—— 它本来就是块级元素，强行改display可能在小屏破坏流式布局 - 别用纯图标无文字（如仅一个 Twitter 图标）—— 缺少可访问性文案，读屏器无法播报联系渠道
真正危险的是：你写了 <address>，但用户根本看不出这是联系信息。问题不在标签本身，而在你没提供足够视觉区分。
address 不生成富摘要，SEO 价值来自语义准确而非标签存在
Google 搜索结果中的电话卡片、营业时间等富摘要，**完全不识别 <address> 标签**。它只服务语义层（辅助技术、开发者理解、基础结构化），不参与搜索引擎富摘要生成。
如果需要让联系方式出现在搜索结果中，必须额外补充：
- JSON-LD 结构化数据，类型为
ContactPoint，放在<head>中 - 确保
<address>内的邮箱、电话链接真实可点击（mailto:/tel:） - 避免 placeholder 邮箱（如
admin@example.com）—— 自动化脚本填入无效地址会损害可信度
最难的部分从来不是语法对不对，而是每次写之前都得确认：这个信息，能不能准确回答「谁写了这篇？谁负责维护？出了问题找谁？」——答不上来，就别用 <address>。
