嗨，正在研究吊索分辨率的工作原理。
我遇到了 Adobe aem-developer guide 中提到的这种情况
https://docs.adobe.com/docs/en/aem/6-2/develop/the-basics.html
这是提到的场景-/a（没有任何资源超类型或资源类型）
b (sling:resourceSuperType = a)
c (sling:resourceSuperType = b)
x (sling:resourceType = c)
y (sling:resourceType = c, sling:resourceSuperType = a)
/x 的类型层次结构是 [ c, b, a, ] 而对于 /y 层次结构是 [ c, a, ] 因为 /y 具有 sling:resourceSuperType 属性而 /x 没有，因此其超类型取自其资源类型。
现在我明白 /x 是如何解决的。但我不确定 /y。首先它解析为/c。它本身有一个 sling:resourceSuperType 作为 b。如果吊索分辨率也不应该转到 /b。如何覆盖超类型并将资源解析为 a 而不是 b。
如Apache Sling 文档 中所述，如果sling:resourceSuperType为特定资源定义了 a，则将使用它。如果它不存在，该框架将使用sling:resourceSuperType定义由指向的资源sling:resourceType。
也就是说，在 的情况下/y，/b不会被视为超类型。在sling:resourceSuperType通过定义/y本身直指/a。它将有效地隐藏sling:resourceSuperType在/c（并指向 ）处定义的属性/b，否则会被考虑在内。
该示例在您链接到的文档页面上得到了很好的描述。
根据我的经验，如果资源类型层次结构由一组定义组件的节点定义并作为/appsor 的后代出现在存储库中/libs（当在继承层次结构中包含 OOTB 组件时），则大多数自定义 AEM 组件更易于维护。/content子树中存在的组件的特定实例（包括负责呈现整个页面的实例）然后可以明确地定义sling:resourceType决定其类型（继承与否）的 a 。就我个人而言，我不喜欢sling:superResourceType在/content作为子树一部分的资源级别定义 ，因为这会使层次结构更难以推理。在我的脑海里，我想不出一个用例来证明这种权衡是合理的。如果他们知道一个好的，也许其他人可以权衡。