微数据是否被识别，关键看 itemscope 和 itemtype 是否成对出现；浏览器和搜索引擎仅当元素同时具备有效的 itemscope 和可访问的 itemtype URL（如 https://schema.org/Person）时才识别，单独 itemprop 无效，且 itemtype 不可缩写或省略协议。
微数据是否被识别，关键看 itemscope 和 itemtype 是否成对出现
浏览器和搜索引擎只在元素同时具备 itemscope（声明一个微数据项）和有效的 itemtype（指向一个已知的词汇表 URL）时，才将其视为可识别的微数据结构。单独写 itemprop 没有意义——它必须嵌套在有 itemscope 的祖先元素内。
-
itemtype必须是完整、可访问的 HTTP/HTTPS URL，例如https://schema.org/Person；http://schema.org/Person也行，但不推荐用短协议（//schema.org/Person）——部分解析器会忽略 - 常见误写：
itemtype="Person"或itemtype="schema:Person"—— 这些不会被任何解析器识别 - 验证工具（如 Google Rich Results Test）会直接忽略无
itemscope的itemprop，控制台也不会报错，容易误以为“写对了”
怎么快速判断页面里有没有被识别的微数据
最直接的方式是用浏览器开发者工具检查 document.getItems()（仅 Chromium 内核支持），或更通用的方法：提取所有带 itemscope 的元素并检查其 itemType 属性值。
const items = document.querySelectorAll('[itemscope]');
items.forEach(el => {
console.log('Scope:', el, 'Type:', el.itemType); // 注意是 itemType（驼峰），不是 itemtype（小写）
});
-
el.itemType返回的是一个DOMSettableTokenList，如果为空或无效 URL，其.length为 0 或内容不可解析 - Safari 和 Firefox 不支持
getItems()，也不暴露itemType属性，所以靠 JS 检测有兼容性盲区；此时只能依赖外部验证工具 - 不要依赖
getAttribute('itemtype')判断有效性——它只是返回字符串，不管 URL 是否合法或能否被解析
常见 schema.org 类型识别失败的三个硬伤
即使语法全对，itemtype 指向 schema.org 也常因细节失效：
- 用了重定向 URL：比如
https://schema.org/Organization是 301 跳转到https://schema.org/Thing的别名页，但某些旧爬虫只认最终目标 URL，建议直接用规范地址（查 schema.org 全量列表确认） -
itemprop值类型不匹配：例如给price传字符串"$29.99"，而 schema.org 要求Number或带content属性的数值，应写作 - 嵌套层级断裂：比如
itemtype="https://schema.org/Restaurant"下写了itemprop="address"，但没在该元素内再加itemscope itemtype="https://schema.org/PostalAddress"—— 地址对象不会被结构化识别
用 itemref 关联跨区域属性时最容易漏掉的检查点
当 itemprop 所在元素不在 itemscope 容器内部时，需用 itemref 引用其 id。但这个机制非常脆弱：
立即学习“前端免费学习笔记（深入）”；
-
itemref只能引用**同级或父级文档流中已存在的元素**，不能跨、不能引用display: none元素（部分解析器会跳过） - 多个
itemref值必须用空格分隔，写成逗号或换行会被当成单个无效 ID - 被引用元素本身**不能有
itemscope**，否则它会被当作独立项处理，导致属性归属错乱
微数据识别不是“写了就生效”，而是“写了 + 符合 schema 约束 + 层级闭合 + URL 可解析 + 工具能抓取”五个条件同时满足。其中The Hobbit
itemtype 的 URL 有效性和嵌套结构完整性，是线上排查时最常卡住的地方。 
