给结构化数据加完hasPart后，AI引用反而掉了两成，我查了三天发现是嵌套层级的事

上周给一个客户站点做结构化数据补全，按schema.org的规范给文章页加了hasPart和isPartOf，想强化页面内部语义关联，理论上对AI抓取应该利好。结果跑了十天，AI引用数从日均42次掉到33次，降了21%。

我以为是页面速度问题，LCP从1.8s涨到2.1s，但压缩了首屏图片后回到1.9s，引用没恢复。又查了JSON-LD语法，validator全绿。最后把新旧两版结构化数据导出来逐字段对比，发现问题出在嵌套层级上。

原来的写法是：WebPage里嵌Article，Article里嵌Person。新加的hasPart直接把Article数组放在WebPage下面，层级从三层变成两层，但Article自己的@type里又带了mainEntity，形成了逻辑上的循环引用。抓取日志里AI爬虫对这部分的解析耗时从平均120ms涨到340ms，有三次直接超时跳过了整个script块。

拆变量重测：我把hasPart单独提出来，只保留isPartOf的向上声明，不嵌套实体，引用数恢复到39次，比基线还低3次。再拆：去掉mainEntity的循环引用，引用回到44次，超过基线。说明问题是循环引用导致解析器放弃，不是hasPart本身。

另一个坑：hasPart里我填的是URL列表，没带name和@type，AI解析时无法判断被链接的资源类型，直接当外链处理了，权重没传递过来。补上name和@type后，引用到46次。

现在我的判断：结构化数据不是越多越好，嵌套深度和引用闭合性比字段数量重要。我准备做一个测试矩阵，把嵌套层数（2/3/4层）和是否循环引用做成2x3的对照组，跑两周看引用数的置信区间。

问一句：你们加hasPart或isPartOf这类关系型字段时，有没有测过解析耗时？我怀疑AI爬虫对嵌套深度的容忍阈值在3层左右，但还没找到对照组验证。