必须使用 breadcrumblist 是因为 schema.org 官方规范将其定为唯一标准类型，google 等搜索引擎仅解析该类型；使用 breadcrumb、mybreadcrumbs 或错误 url（如 http://schema.org/breadcrumb）均会导致校验失败、富摘要不显示。
Google 只认 BreadcrumbList 这一种类型，写成 Breadcrumb、MyBreadcrumbs 或任何其他名字都无效——结构化数据校验会直接失败，搜索结果里也不会出现富摘要。
为什么必须用 BreadcrumbList 而不是别的类型
Schema.org 官方规范明确将面包屑定义为 BreadcrumbList 类型，Google、Bing 等主流搜索引擎只解析这个类型。旧文档里出现的 http://schema.org/Breadcrumb 是过时链接，已废弃多年；抄错链接或自定义类型名会导致整个 JSON-LD 被忽略。
常见错误现象包括：
- Rich Results Test 工具报 “
Missing field "@type"” 或 “Invalid @type value” - Search Console 中结构化数据报告里该页面条目为空白或显示“未检测到”
- 明明写了 JSON-LD，但搜索结果始终不显示层级路径
itemListElement 数组必须严格满足三项条件
这个数组不是可选字段，是 BreadcrumbList 的强制要求。每个元素必须是 ListItem 对象，且顺序、字段、取值都不能出错。
关键约束点：
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
-
position必须从1开始连续递增（不能是0、2起跳，也不能跳号如1, 2, 4） - 每个元素必须含
@type: "ListItem"——漏掉这个字段，Google 会当作普通对象忽略 -
item字段必须是对象，至少含@id（推荐绝对 URL）或name；仅写字符串如"https://example.com/"会被判定为格式错误
示例正确写法：
{ "@type": "ListItem", "position": 2, "name": "博客", "item": { "@id": "https://example.com/blog/" } }
@context 和 URL 必须绝对、一致、可访问
@context 必须是 "https://schema.org"，少一个 s、多一个斜杠、写成 http 都不行。URL 必须是完整绝对路径，且与页面的 <link rel="canonical"> 完全一致。
容易被忽略的坑：
- 本地开发用
http://localhost:3000/测试，上线后忘了替换成正式域名，导致所有itemURL 返回 404 - 某级面包屑指向的 URL 有重定向（比如 301 跳转），跳转链超过 5 次，Google 会放弃抓取并标记为无效
- 多语言站点中，
@id值没和hreflang属性对齐，比如中文页的@id写了英文 URL，造成语义冲突
script 标签位置和转义比内容本身更容易出问题
JSON-LD 必须放在 或 顶部，不能包裹在 <div> 或其他 HTML 元素内。如果通过 JS 动态注入，一旦执行失败或被广告拦截器屏蔽，整个结构化数据就丢失了。
<p>特别注意：</p>
<ul>
<li>HTML 中嵌入 JSON-LD 时，所有双引号、反斜杠、换行符必须正确转义，否则浏览器解析 script 会中断</li>
<li>服务端渲染（SSR）场景下，若模板引擎自动转义 JSON 字符串（如把 <code>" 变成 "），会导致 JSON-LD 语法错误
最稳妥的做法：静态生成 JSON-LD 字符串，用 <script type="application/ld+json"></script> 直接内联，避免任何运行时处理。
