直接答案：粘贴 JSON-LD 或整段 HTML，工具在浏览器本地做四件事：提取所有 application/ld+json 块并解析；展开数组与 @graph；按 13 类常见 @type 检查必填字段；把 name/headline 与可见正文比对。它不联网、不抓站，也不保证富媒体结果。
我们自己的扫描里，结构化数据是最薄的一层：30 家装备企业首页有 JSON-LD 的 5 家，15 个产品页里只有 1 个，20 个联系页里 0 个用了 ContactPage。但“有没有”只是第一问，第二问是“写了之后能不能用”——这一层几乎没有工具检查，通常靠人工看源码。
能不能解析？
@graph 里的节点有没有被算进去？
这类 @type 的必填字段齐不齐？
写的名称在页面上找得到吗？
工具：粘贴 → 检查
| # | @type | 名称 | 正文匹配 | 问题 |
|---|
“未填正文”时不做一致性判断；@id 重复、建议字段缺失只记为警告，不阻断。
默认示例里，Organization 完整，Product 缺 offers——所以会看到 1 条错误和若干建议；两个名称都能在下方正文里找到，因此“正文匹配”都显示“匹配”。把正文里的产品名删掉，会立刻变成“未找到”，并给出警告。
检查规则
| @type | 必填（错误） | 建议（警告） |
|---|---|---|
| Organization | name、url | logo、sameAs、address |
| LocalBusiness | name、address | telephone、url |
| Product | name + offers/review/aggregateRating 之一 | — |
| FAQPage | mainEntity（数组） | 每项 question name + acceptedAnswer.text |
| BreadcrumbList | itemListElement | 每项 position、name/item |
| BlogPosting / NewsArticle / Article | headline、author、datePublished | image |
| WebSite / WebPage / ContactPage | url（WebSite 另需 name） | name |
| Person | name | — |
必填是本工具的口径，不是 schema.org 的合法性判定；其他 @type 仍会解析并做正文比对，只是提示“未内置规则”。
五个常见失败
- 解析失败。 尾逗号、单引号、注释、BOM 都会让
JSON.parse直接报错；页面看起来正常，标记其实整块失效。 - @graph 没展开。 很多站点把节点包在
@graph里；只取顶层@type会得到 0 个节点。 - @id 重复。 同一实体在多个块里重复声明，且字段不一致时，机器无法判断以哪个为准。
- 缺关键字段。 Product 只有 name、没有 offers；FAQPage 的 mainEntity 不是数组——语法都对，但拿不到对应结果。
- 标记与正文不符。 名称、价格、评分写了页面上没有的内容；一致性比对是最低成本的筛查。
边界
- 不抓站：只分析粘贴文本，不知道线上实际输出。
- 不是完整校验器：不覆盖 schema.org 全部类型与继承，也不检查嵌套节点（如
publisher内部）。 - 不保证富媒体：语法与字段通过只是候选条件，展示由搜索引擎决定。
- 一致性只比名称：价格、评分、日期需要更多上下文，误判率高，留给人工。
测试与复算
逻辑在 js/jsonld-check.js（无依赖、无网络）；scripts/test_jsonld_check.js 覆盖 60 条断言：提取、数组与 @graph 展开、解析错误、13 类规则、FAQ/面包屑结构、@id 重复、正文归一化与匹配、未知类型、空输入。运行：
node scripts/test_jsonld_check.js
配套：12 条验收条款模板（第 5 条即结构化数据）、验收证据包生成器、30 家装备企业扫描（JSON-LD 5/25）、15 个产品页 pilot（JSON-LD 1/13）。
数据来源与口径
- schema.org 类型与属性：schema.org。
- JSON 语法：RFC 8259：rfc-editor.org。
- 示例中的组织信息来自本站公开资料；示例产品名仅用于演示字段缺失，不构成产品承诺。