HTML5微数据识别的关键是itemscope与itemtype必须成对出现在同一元素上，且itemtype须为合法schema.org绝对URL；单独itemscope或无效itemtype均不被解析。
itemscope 不是 CSS 作用域，也不是 JS 变量作用域，它只干一件事：告诉搜索引擎和解析器——“从这里开始，是一组有明确语义的结构化数据”。用错地方或孤立使用，基本等于没写。
itemscope 必须搭配 itemtype 才有效
单独写 itemscope 没意义。浏览器或爬虫看到它，只会知道“这里有个新项目”，但完全不知道这个项目是什么类型（人？电影？餐厅？），也就无法正确提取字段。
-
itemscope定义作用域边界，itemtype指定语义类型，二者必须同时出现在同一个元素上 -
itemtype值必须是合法的词汇表 URL，比如http://schema.org/Person或https://schema.org/Restaurant；用错协议（如http写成https）或拼错路径，Google Rich Results Test 就会静默忽略整块微数据 - 常见错误：把
itemtype写成本地路径、相对 URL 或空字符串，例如itemtype="Person"或itemtype="./schema.json"—— 这些全无效
嵌套 itemscope 是结构化数据的常规操作
真实数据往往有层级，比如“一家餐厅”包含“地址”、“营业时间”、“菜单项”，而“地址”本身又含“街道”“城市”“邮编”。这时就得用嵌套 itemscope。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 内层
itemscope元素必须有自己的itemtype，不能复用外层的；例如餐厅用itemtype="https://schema.org/Restaurant"，其内部地址要用itemtype="https://schema.org/PostalAddress" - 嵌套时不用显式声明关系，靠 DOM 层级自动关联；但若跨节点引用（比如地址信息分散在不同 div），就得用
itemref配合id，否则解析器无法拼合 - 别为了“看起来整齐”强行扁平化嵌套——结构失真比多几层 div 更伤 SEO
scope 属性和 itemscope 完全无关，别混
HTML 表格里的 scope（如 scope="col"）是可访问性属性，专用于 <th>；CSS 的 <code>@scope 是样式作用域机制；而 itemscope 是微数据语义标记。三者命名撞车，但实现、用途、生效环境全不重叠。
立即学习“前端免费学习笔记（深入）”；
- 在表格里写
<th itemscope> 不会增强可访问性，也不会触发微数据解析——因为缺 <code>itemtype，且<th> 通常不是包裹完整实体的容器 <li>在 CSS 里写 <code>@scope (.card) { ... }和itemscope毫无关系；就算 HTML 里有<div itemscope itemtype="...">，也绝不会影响该 <code>@scope规则是否生效 - 混淆这三者，是调试时查半天控制台却找不到问题根源的最常见原因
真正容易被忽略的是：微数据解析器对 DOM 结构非常敏感。哪怕 itemscope 和 itemtype 都写对了，如果包裹的内容里混入了未闭合标签、非法嵌套（比如 <p></p> 里直接放 <div itemscope>），或者用了自定义元素但没定义 <code>is 属性，整个 itemscope 区块都可能被跳过。验证务必用 Google 的 Rich Results Test 工具，而不是只看 DevTools 里有没有高亮。
