JSON-LD 的 @id 写错作用域，AI 摘录直接张冠李戴

上周跑批发现一个邪门问题：同一个产品页，AI 摘录里把「保修期」写成了「7天无理由退货」，还理直气壮引用了我们的 FAQ 段落。我一开始以为是模型幻觉，但把页面 JSON-LD 拉出来看，根子其实在 @id 的作用域上。

先定口径：我这次只验证「同一实体下多个问答节点是否共享了错误的 @id 前缀」。页面里有 Product 和 FAQPage 两个块，FAQPage 的 mainEntity 里每个 Question 节点我都用了 @id，但写法是 #faq-1、#faq-2 这种相对片段。问题出在 FAQPage 的 @id 我写成了 https://example.com/product#faq，而 Question 的 @id 没带绝对路径，解析器就把它们挂到了 Product 实体下。AI 抓取时按 @id 归并实体，结果保修期和退货政策两个 Answer 被合并成一个，模型直接串了。

实测数据：修正前，用 Rich Results Test 跑，FAQ 的 mainEntity 被识别为 Product 的 subjectOf，而不是独立 FAQPage。修正后，把每个 Question 的 @id 改成绝对 URL 并确保父级作用域是 FAQPage，同一批问句的 AI 摘录准确率从 62% 拉到 91%（样本 120 条，人工核验）。

踩坑细节：JSON-LD 里 @id 不是随便写个锚点就行，它本质是全局标识符。相对 @id 在不同解析器里行为不一致，Google 的解析器会按文档基址补全，但部分 AI 爬虫的 JSON-LD 处理器不补，直接当字符串比较。所以要么全用绝对 URL，要么就别用 @id 做嵌套引用，改用 @graph 显式声明节点关系。

我的判断依据：抓取日志里，FAQ 节点的 @id 和 Product 的 @id 共享了同一个前缀，导致实体合并。页面速度这块我也顺带看了，修正后页面大小只增加了 1.2KB，LCP 没变化，所以不是性能问题，纯粹是结构化数据语义问题。

现在我的做法是：每个可被独立引用的实体都给它绝对 @id，并在 @graph 里显式列出所有节点，避免隐式嵌套。验收标准先锁死：随机抽 10 个问句，AI 摘录的 Answer 必须和页面 FAQ 原文完全一致，差一个字都算失败。

你们在 JSON-LD 里用 @id 时，是习惯写绝对 URL 还是相对片段？有没有遇到过不同解析器行为分裂的情况？