address标签仅声明联系人语义，不承载结构化地理数据；地理位置信息需通过schema.org（如PostalAddress）、JSON-LD等外部标记显式定义，二者须双轨并行、不可混用。
address 标签本身不承载地理位置结构化数据，它只负责语义声明“谁写了这个页面/文章、怎么联系他”。它不解析、不绑定、也不输出经纬度、行政区划、邮编等地理字段——这些属于结构化数据范畴，需由 schema.org（如 PostalAddress）、JSON-LD 或微数据显式定义。
真正实现地理位置信息结构标准化的，是 配合 address 使用的外部标记方案，而非 address 自身。
✅ 正确做法：address + 结构化数据双轨并行
address 提供人可读、机器可识别的责任归属语义；
结构化数据（如 JSON-LD）提供机器可解析的地理坐标与层级字段。
示例：个人博客页脚（作者办公地址）
<!-- 语义正确的 address —— 告诉辅助技术“这是作者的联络方式” -->
<address>
来信请寄：北京市朝阳区建国路1号（前端组收）<br>
邮箱：<a href="mailto:me@example.com">me@example.com</a><br>
电话：<a href="tel:+861012345678">+86 10 1234 5678</a>
</address>
<!-- 同一页面嵌入 JSON-LD —— 告诉搜索引擎这是哪个实体的精确地理信息 -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"name": "张三",
"jobTitle": "前端开发者",
"address": {
"@type": "PostalAddress",
"streetAddress": "建国路1号",
"addressLocality": "朝阳区",
"addressRegion": "北京市",
"postalCode": "100022",
"addressCountry": "CN"
},
"email": "me@example.com",
"telephone": "+861012345678"
}
</script>⚠️ 注意：
address内部不能写itemprop="streetAddress"等微数据属性——它只接受 phrasing content，且微数据若放在address里，可能因作用域冲突被爬虫忽略。
❌ 常见误用（破坏标准化）
| 错误写法 | 问题 |
|---|---|
<address itemscope itemtype="https://schema.org/PostalAddress"> |
address 不是容器型元素，itemscope 在其中无效，且违反 HTML5 内容模型 |
<address><span itemprop="addressLocality">朝阳区</span></address> |
屏幕阅读器仍只读作“联系信息”，但 itemprop 未绑定到有效实体根节点，结构化数据不可信 |
单独用 <address>北京市朝阳区建国路1号</address>
|
无责任人动作（如“来信请寄”）、无可交互方式（无 mailto/tel），语义失效，结构化字段无法映射 |
? 地理位置字段应按 schema.org 规范组织
标准 PostalAddress 必须包含以下至少部分字段（推荐全量）：
-
streetAddress（街道门牌） -
addressLocality（区/县/镇） -
addressRegion（省/州） -
postalCode（邮编） -
addressCountry（国家，推荐用 ISO 3166-1 alpha-2 代码，如"CN"） - 可选：
latlng（经纬度对象）、telephone、email
Places.js 等地理服务返回的
countryCode,suburb,county等字段，可直接映射到对应 schema 字段，但必须挂载在有效的@type实体下（如Person,Organization,LocalBusiness），不能悬空。
? 验证是否达标
- ✅
address是<body>或<article>的直接子元素 - ✅ 内容含明确责任人 + 可交互方式（
mailto:/tel:/ 显式动作动词） - ✅ 地理结构化数据独立存在（JSON-LD 最佳），且
@id或上下文能关联到同一主体 - ✅ 不在
address中嵌套p,div,ul,h3等块级元素
不复杂但容易忽略。
