我一直在重构现有的 Umbraco 项目，以便在取回文档数据时使用更高性能的查询，因为之前所有内容都是使用 LINQ 返回的。我一直在使用 Umbraco 通过 XPaths 和 Examine 进行查询的组合。
我目前很难尝试使用该Umbraco.ContentAtXPath()方法获取子文档。我想做的是根据我解析到该方法的路径获取子文档。这是我目前拥有的：
IEnumerable<IPublishedContent> umbracoPages = Umbraco.ContentAtXPath("//* [@isDoc]/descendant::/About [@isDoc]");
运行此返回“对象引用未设置为对象的实例”。错误并且无法确切地看到我哪里出错了（Umbraco 中这种查询形式的新手）。
理想情况下，我想增强查询以使用非 LINQ 方法进行排序，如此处所示。
在 Umbraco 8 中查询 NuCache 非常快，仅被检查搜索击败。假设您使用的是 Models Builder，并且您的 About 页面是 Home 页面的子页面，您可以使用：
var homePage = (HomePage) Model.Root();
var aboutPage = homePage?.Children<AboutPage>().FirstOrDefault();
var umbracoPages = aboutPage.Children();
HomePage您的主页文档类型别名在哪里，AboutPage您的关于页面文档类型别名在哪里。
在 Umbraco 8 之前，内容被缓存在一个 XML 文件中，这使得 XPath 非常适合高效地查询内容。然而，在 v8 中，所谓的“NuCache”既不是基于文件也不是基于 XML，所以 XPath 查询支持只是为了……好吧……我猜是旧时代的缘故吧？无论哪种方式，它都可能不会超级高效，并且（我建议）不是“瞄准”的东西。那就是说我当然不知道您要改变什么（Linq 可以是很多东西）：-/
这当然取决于您的数据集有多大。
由于 Umbraco 已经远离 XML 支持的缓存，您应该查看针对您的内容模型的 Linq 查询。确保使用 ModelsBuilder 生成模型。
在小数据集上，Linq 会比检查快得多。在大型数据集上，Examine/Lucene 的性能会更加稳定。