标签无效是因为它仅用于标记作者联系信息，非通用地址展示，且默认样式简陋、常被过滤或重置；应改用schema.org结构化标记。
为什么直接写 <address></address> 标签没效果
浏览器确实支持 <address></address>，但它不是“显示联系地址的万能标签”，而是语义化标签，仅用于标记文档或章节的作者/拥有者联系信息。默认样式极简（通常只是斜体+换行），且现代 CMS、模板引擎或富文本编辑器常过滤掉该标签——你写了，但可能根本没渲染出来。
常见错误现象：<address>北京市朝阳区XX路1号</address> 在页面上看起来和普通段落没区别，甚至被 CSS 重置掉了所有样式。
- 它不自动加图标、不换行布局、不带结构化语义（如 schema.org 识别不了）
- 搜索引擎和读屏器对它的语义理解有限，远不如用
<div> + <code>itemprop="address"明确 - HTML5 规范明确说：它“不应”用于任意联系信息（比如客服地址、门店地址），只适用于当前页面内容的作者信息
用 <div> + <code>itemscope + itemtype 实现可读又可索引的地址
真正让地址“被看见”的方式，是结构化标记 + 基础样式控制。Schema.org 的 PostalAddress 是最通用、搜索引擎最认可的方案。
示例代码：
<div itemscope itemtype="https://schema.org/PostalAddress"> <span itemprop="streetAddress">北京市朝阳区建国路87号</span>， <span itemprop="addressLocality">朝阳区</span> <span itemprop="addressRegion">北京市</span> <span itemprop="postalCode">100022</span> </div>
-
itemscope和itemtype让搜索引擎识别这是个地址实体 -
itemprop属性名必须严格匹配 schema.org 定义，错一个字母（如streetaddress小写）就失效 - 中文地址建议拆解为
streetAddress+addressLocality+addressRegion，避免全塞进streetAddress导致结构混乱
CSS 控制显示样式时，避开 <address></address> 的默认行为
如果你坚持用 <address></address>（比如 legacy 项目不能改 HTML 结构），就得手动覆盖其不可靠的默认样式。
- 它默认是
display: block; font-style: italic;，但不同浏览器斜体程度不同，且无 margin/padding 一致性 - 务必重置：
address { font-style: normal; margin: 0; padding: 0; line-height: 1.5; } - 如果要加地图图标或“地址：”前缀，必须用伪元素或额外 HTML——
<address></address>本身不支持插入内容 - 响应式场景下，用
flex或grid布局地址行更可控，而<address></address>是纯流式块级，难以微调换行点
后端或 CMS 输出地址时，别依赖前端自动补全 <address></address>
很多开发者以为模板里写 {{ contact_address }}，再套个 <address></address> 就万事大吉。实际中容易出问题：
- 用户输入的地址含 HTML 标签（如
<br>），直接插入<address></address>可能破坏结构 - 国际化地址字段顺序不同（日本是邮编在前，中国在后），硬编码
<address></address>内容无法适配 - 静态站点生成器（如 Hugo、Jekyll）若未启用 HTML 转义解除，
<address></address>标签会被当成纯文本输出
真正稳妥的做法：后端返回结构化 JSON（含 street、city、postal_code 字段），前端用模板逻辑按需拼接，并始终用 <div itemscope> 包裹。
<p>复杂点在于地址字段的边界处理——比如“上海市浦东新区张江路1号”里，“浦东新区”是 <code>addressLocality 还是 addressRegion？这没有绝对标准，但一旦选错，Google 富摘要就不会展示地图卡片。这事得和 SEO 团队对齐，不能只看前端渲染是否“看起来对”。
