XPath中//和descendant::轴的核心区别在于：//是descendant-or-self::node()/的简写，包含当前节点自身及所有后代，而descendant::仅选择后代节点不包括自身。//语法简洁常用于全局搜索，如//div查找所有div元素；descendant::语义明确，适用于需精准控制范围的场景，如/html/body/descendant::div仅选body下的后代div。性能上，//可能因遍历范围广而稍慢，尤其在大型文档中，但现代引擎常优化此差异。实际使用中，//更便捷，descendant::在复杂查询中可读性更强。
<p>
<p>XPath选择后代节点的核心手段是使用
操作符，或者更明确地通过
轴。在我看来，这两种方式都是为了解决同一个问题：从当前上下文节点向下，无论层级多深，找到所有符合条件的子孙节点。简单来说，
就是
descendant-or-self::node()/
登录后复制
的一个方便快捷的缩写，它会从当前节点（包括自身）开始，沿着所有可能的路径，寻找指定名称的节点。
<p>深入探讨这两种选择后代节点的方式，我发现它们各有千秋，理解它们背后的逻辑对于高效编写XPath表达式至关重要。
<p>
操作符是我日常中最常用的。当你需要从文档的任何位置，或者从某个特定节点开始，向下搜寻一个元素时，
简直是神器。比如，如果你想找到页面上所有的
元素，不管它们嵌套在多少层父级之下，一个简单的
就能搞定。它的语法简洁，直观，但这种便利性背后也藏着一些需要注意的地方——它会遍历整个子树，在非常庞大复杂的文档中，这可能会带来一定的性能开销。就好比你在一个大图书馆里找一本书，如果你知道它在哪个区域，直接去那个区域找会快很多；但如果你只知道书名，然后从头到尾一排排地找，效率自然会低一些。
<p>例如：
- ：选择文档中所有的元素。
- ：选择元素下的元素中的所有元素，无论元素嵌套多深。
<p>
轴提供了更明确的语义。它清晰地表明你正在寻找当前节点的所有后代节点。虽然
在大多数情况下能完成任务，但
轴在某些场景下，尤其是当你需要结合其他轴或者更精细地控制搜索范围时，会显得更有条理和可读性。它不会包含当前节点自身，只专注于其下方的子孙。
<p>例如：
/html/body/descendant::div
登录后复制
//div[@id='container']/descendant::span
登录后复制
<p>在我看来，选择哪种方式，很多时候取决于你的具体需求和个人习惯。
的简洁性让人爱不释手，而
的明确性则在复杂查询中提供了更好的结构。
XPath中和轴有什么区别？
<p>这个问题经常被人提及，也确实值得我们花点时间理清。从表面上看，它们都能用来选择后代节点，但其内在机制和适用场景还是有些微妙的差异。我个人总结下来，主要有以下几点：
-
<p>语法上的差异：
- 是一个简写符号，它等同于
descendant-or-self::node()/
登录后复制
- 是一个明确的轴名称，它只查找当前上下文节点的后代节点，不包括当前节点本身。
-
<p>搜索范围的起点：
- 当出现在路径的开头时（例如），它表示从文档的根节点开始，查找文档中所有符合条件的元素。
- 当出现在路径的中间时（例如），它表示从节点开始，查找其所有后代元素。
- 轴总是相对于其前面的上下文节点来操作。例如，
/html/body/descendant::p
登录后复制
-
<p>性能考量：
- 理论上，由于其“全局”或“任意层级”的特性，在处理大型XML/HTML文档时，如果使用不当，可能会比明确限定范围的路径（比如结合或更具体的父节点）效率稍低。因为它需要遍历更多的节点。不过，现代XPath引擎和浏览器通常会对其进行优化。
- 轴虽然语义更明确，但其本质与在寻找后代节点时的工作方式是类似的，性能差异往往体现在上下文的限制上。如果能将搜索范围限制在一个更小的父节点下，性能自然会更好。
<p>举个例子，假设我们有一个HTML结构：
<html>
<body>
<p>Content text 1
<p>Content text 2 (nested)
0
