@graph 是 JSON-LD 规范提供的核心机制，允许在单个 标签中声明多个独立、异构的 Schema.org 实体（如 MedicalCondition、Person、Review、VideoObject），无需强制类型统一或层级嵌套。
`@graph` 是 json-ld 规范提供的核心机制，允许在单个 `<script type="application/ld+json">` 标签中声明多个独立、异构的 schema.org 实体（如 `medicalcondition`、`person`、`review`、`videoobject`），无需强制类型统一或层级嵌套。</script>
在实际网页结构化标记实践中，一个页面往往承载多种语义实体——例如医疗类页面可能同时包含疾病信息、主治医生介绍、患者评价及科普视频。此时，使用 @graph 不仅合法，而且是推荐做法：它避免了为兼容性而强行构造“父容器”（如用 WebPage 包裹所有内容），也规避了因过度嵌套导致的逻辑失真与验证失败。
✅ 正确用法：@graph 支持任意类型混合
根据 JSON-LD 1.1 规范 及 Schema.org 官方文档，@graph 字段用于定义一个命名图（named graph），其值为对象数组，每个对象可独立声明 @type，类型之间无继承或约束关系。这意味着：
- ✅ 可混合
MedicalCondition、Person、Review、VideoObject等不同类型； - ✅ 各实体彼此平级，互不隶属，语义清晰；
- ✅ 每个对象必须包含有效
@type和必要属性（如name、url），否则将被搜索引擎忽略。
以下为修正后的合规示例（已修复原代码中的拼写错误、语法缺失及结构冗余）：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "MedicalCondition",
"name": "2型糖尿病",
"description": "一种慢性代谢性疾病，特征为高血糖。",
"associatedAnatomy": {
"@type": "AnatomicalStructure",
"name": "胰腺"
},
"signOrSymptom": [
{ "@type": "MedicalSignOrSymptom", "name": "多饮" },
{ "@type": "MedicalSignOrSymptom", "name": "多尿" }
],
"possibleTreatment": [
{ "@type": "MedicalTherapy", "name": "二甲双胍治疗" }
]
},
{
"@type": "Person",
"name": "张明医生",
"jobTitle": "内分泌科主任医师",
"affiliation": {
"@type": "Organization",
"name": "北京协和医院"
},
"alumniOf": [
{ "@type": "EducationalOrganization", "name": "北京大学医学部" }
]
},
{
"@type": "Review",
"author": { "@type": "Person", "name": "李女士" },
"reviewBody": "张医生耐心细致，治疗方案很个性化。",
"itemReviewed": { "@type": "MedicalCondition", "name": "2型糖尿病" },
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"worstRating": "1",
"bestRating": "5"
}
},
{
"@type": "VideoObject",
"name": "糖尿病饮食管理指南",
"description": "营养师讲解日常饮食控制要点。",
"uploadDate": "2026-07-15",
"duration": "PT8M32S",
"contentUrl": "https://example.com/videos/diabetes-diet.mp4",
"thumbnailUrl": ["https://example.com/thumbs/diabetes-diet.jpg"],
"embedUrl": "https://example.com/embed/diabetes-diet"
}
]
}
</script>⚠️ 注意事项与常见误区
-
拼写与语法必须严格校验：原问题中存在
Perosn（应为Person）、缺失数值（如"ratingValue":,）、空属性名（如"": [...]）等错误，会导致整个 JSON-LD 解析失败。建议使用 Google Rich Results Test 或 Schema Markup Validator 实时验证。 -
避免冗余重复：多个同类实体（如 5 条
Review）应确保每条数据真实有效；批量生成时需防止@id缺失导致去重失败（虽非必需，但推荐为每个实体添加唯一@id以提升可追溯性）。 -
不等于“类型聚合”：
@graph≠ 类型分组工具。它不改变各实体的独立性，也不赋予它们共同父类型。若需表达“该页面描述某疾病及其相关医生与视频”，应在 HTML 文档结构或mainEntity属性中显式建模，而非依赖@graph隐含关系。 -
兼容性无忧：主流搜索引擎（Google、Bing、Yandex）及 AI Agent 工具（如支持 MCP 协议的采购智能体）均完整支持
@graph，且将其视为标准多实体标记方式——这正是面向 Agent 的 GEO（生成式引擎优化）所依赖的基础能力之一。
综上，@graph 不仅允许、而且鼓励跨类型结构化数据共存。它是现代语义 Web 实践中实现精准、灵活、可扩展标记的关键语法，也是从“页面 SEO”迈向“实体优先、Agent 可调用”的基础设施基石。
