联系方式必须用 https://schema.org/ContactPoint，而非 Person 或 Organization；必需 contactType，嵌套于 Organization 的 contactPoint 属性中，JSON-LD 推荐且需规范书写。
itemtype 应该用 schema.org 的哪个类型
描述联系方式必须用 https://schema.org/ContactPoint，不是 Person 或 Organization——后者是主体，前者才是“联系方式”这个抽象实体。用错类型会导致搜索引擎无法解析出电话、邮箱等字段。
常见错误是直接套用 https://schema.org/Person 并在里头塞 telephone，这样结构对但语义错：搜索引擎会认为“这个人”本身是联系方式，而非“这个人有一个联系方式”。
必需的属性和常见可选字段
ContactPoint 要生效，至少得有 contactType（哪怕只是写 "customer service"），否则 Google Rich Results 测试工具会报 Missing field 'contactType'。
实际使用中按需加以下字段：
立即学习“前端免费学习笔记（深入）”；
-
telephone：带国际区号更稳妥，例如+86 138-0013-8000；纯数字（如13800138000）也能识别，但易被误判为 ID -
email：必须是完整邮箱格式，mailto:xxx@domain.com不行，只写xxx@domain.com -
areaServed：国家代码推荐用"CN"，城市名如"Beijing"（英文）或"北京市"（中文也支持，但建议统一用英文以保兼容） -
availableLanguage：值是字符串数组，如["zh", "en"]，不能写成"zh, en"
嵌套在 Organization 里时怎么写结构
多数场景下，联系方式属于公司，所以 ContactPoint 要作为 Organization 的 contactPoint 属性值，而不是平级并列。结构错会导致字段丢失。
正确嵌套示例（Microdata）：
<div itemscope itemtype="https://schema.org/Organization">
<span itemprop="name">某某科技有限公司</span>
<div itemprop="contactPoint" itemscope itemtype="https://schema.org/ContactPoint">
<meta itemprop="contactType" content="customer service">
<meta itemprop="telephone" content="+86 10-1234-5678">
<meta itemprop="email" content="service@example.com">
<meta itemprop="areaServed" content="CN">
</div>
</div>
注意：contactPoint 是复数形式的属性名，但一个 Organization 可以有多个 contactPoint 块，每个块描述一种渠道（客服电话、售后邮箱、技术支持微信等）。
JSON-LD 方式更可靠，但要注意 script 位置
比起 Microdata，JSON-LD 更少受 HTML 结构干扰，推荐用于页脚或 中。但必须确保 <script type="application/ld+json"></script> 在 DOM 加载前已存在，否则某些爬虫可能跳过。
关键点：
-
@context必须是"https://schema.org"，不能省略或写错 -
contactPoint字段值必须是对象数组，哪怕只有一个联系点也要写成[{...}] - 避免在 JSON 中混用中文键名（如把
telephone写成电话），所有属性名必须用英文 schema 定义名
容易被忽略的是：如果页面同时用了 Microdata 和 JSON-LD 描述同一实体，Google 会优先采用 JSON-LD，但若两者冲突（比如电话号码不一致），可能触发警告甚至降权。
