itemtype值不必等于JSON-LD的@type，但需指向schema.org下可解析的绝对URL（如https://schema.org/Person），而JSON-LD中@type可用短名“Person”；二者语义等价但语法不同，微数据强制URL格式，JSON-LD更灵活。
itemtype 值必须是 JSON-LD 中的 @type 吗？
不是必须，但强烈建议保持一致。HTML 的 itemtype 属性值是一个 URL（如 https://schema.org/Person），它在微数据规范中标识类型；而 JSON-LD 的 @type 字段可以是字符串（如 "Person"）或带前缀的 URL（如 "https://schema.org/Person"）。实际解析器（如 Google Rich Results Test）会把 itemtype="https://schema.org/Person" 映射为 @type: "Person"，前提是该 URL 在 schema.org 命名空间下且可解析。
常见错误现象：itemtype="Person"（缺协议和域名）会导致微数据失效，JSON-LD 也不会自动补全；同样，@type: "https://example.com/CustomType" 若未在 @context 中声明，JSON-LD 解析器可能忽略或报错。
- 微数据中的
itemtype必须是绝对 URL，不能是相对路径或简写 - JSON-LD 中
@type推荐用短名称（如"Article"），前提是@context已设为"https://schema.org/" - 若需自定义类型，JSON-LD 要显式扩展
@context，而微数据无法等效表达——这是单向兼容缺口
如何从 itemscope itemtype 结构生成等效 JSON-LD？
核心是提取嵌套结构、属性名和值，并映射到 JSON-LD 对象树。注意：微数据靠 DOM 层级和 itemprop 定位属性，JSON-LD 靠键值对和嵌套对象。
例如这段 HTML：
立即学习“前端免费学习笔记（深入）”；
<div itemscope itemtype="https://schema.org/Person">
<span itemprop="name">张三</span>
<div itemprop="jobTitle">前端工程师</div>
<div itemprop="alumniOf" itemscope itemtype="https://schema.org/EducationalOrganization">
<span itemprop="name">清华大学</span>
</div>
</div>
对应 JSON-LD 应为：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
{
"@context": "https://schema.org/",
"@type": "Person",
"name": "张三",
"jobTitle": "前端工程师",
"alumniOf": {
"@type": "EducationalOrganization",
"name": "清华大学"
}
}
-
itemprop名直接转为 JSON-LD 键名（如jobTitle→"jobTitle"） - 嵌套的
itemscope转为嵌套对象，且必须包含@type（即使父级已有@context） - 多值属性（如多个
itemprop="award"）需转为数组，不能只取第一个 - 日期、数字等类型字段不会自动转换——
<time itemprop="birthDate" datetime="1990-05-12">的值应取datetime属性而非文本内容
JSON-LD 能否反向生成合法微数据？
能，但有明确限制：JSON-LD 支持的某些结构无法用微数据表达，比如数组中的混合类型、深层嵌套的无类型对象、或使用 @id 关联多个节点的场景。
典型不可逆情况：
- JSON-LD 中
"knowsLanguage": ["en", "zh"]→ 微数据只能逐个写<meta itemprop="knowsLanguage" content="en">，但无法表示“这是一个语言列表”语义（微数据无原生数组概念） -
"sameAs": ["https://github.com/zhangsan", "https://twitter.com/z3"]→ 微数据只能用多个<link itemprop="sameAs" href="...">，但丢失了字段聚合意图 - 含
@id的引用（如"author": {"@id": "_:b1"}）→ 微数据没有等效锚点机制，无法跨元素复用同一实体
工具链上，Google 的 Rich Results Test 只校验输出结果是否被识别，不验证双向等价性。别指望 JSON-LD 转出的 HTML 能 100% 还原原始结构。
为什么用 JSON-LD 而不用微数据？
根本原因不是语法简洁，而是解耦与可控性。JSON-LD 可以集中放在 <head> 或页面末尾，不干扰 HTML 结构；而微数据强制绑定 DOM，一旦模板重构或 CMS 输出变动，itemprop 很容易错位或遗漏。
更关键的是执行时机：
- 微数据依赖浏览器解析 DOM 树，SPA 中动态插入的内容若没触发
itemscope重扫描，搜索引擎可能抓不到 - JSON-LD 是纯数据块，只要 script 标签存在且 type 为
"application/ld+json"，解析器会在加载时立即提取，不依赖渲染状态 - 服务端渲染（SSR）场景下，JSON-LD 可由后端直接注入；微数据则需确保 HTML 模板每处
itemprop都与数据上下文严格对齐，容错率低
真正容易被忽略的点：很多团队把 JSON-LD 当作“补丁”加在页面底部，却没删掉原有微数据——重复声明同一实体可能导致结构化数据冲突或去重失败。要么全用 JSON-LD，要么彻底清理微数据残留。
