在XML数据处理领域，XQuery和XPath经常成对出现，但它们承担的角色并不一样。XPath更像一把精准的镊子，负责在文档树里夹出满足条件的节点；XQuery则是一整套加工台，既能用XPath捡料，也能把捡来的料按规则打磨、拼接、输出成全新文档。不少初学者把两者混为一谈，结果在只需要简单取值的场景里硬写XQuery，或者在要做多步转换时只用XPath干瞪眼。
XPath的核心机制与语法边界
XPath全称为XML Path Language，它本质上是一种用来在XML文档中导航和寻址的语言。XPath把XML文档看作一棵节点树，包含元素节点、属性节点、文本节点等七种节点类型。最基础的写法是绝对路径，以斜杠开头从根节点逐层向下，例如 /bookstore/book/title 表示取根下书店里所有书的标题。相对路径则从上下文节点出发，用 book/price 表示当前节点子书的售价。 predicates（谓词）用方括号过滤，像 book[price>30] 选取价格高于三十的书。
XPath自身不具备变量声明、循环控制或结果重构能力。它输出的要么是节点集，要么是字符串、数值、布尔值等原子值。这意味着如果你只想在配置文件里抠出某个端口号，或者在前端用JavaScript的 evaluate 方法抽一段文本，XPath足够且轻量。但一旦需求变成把选取的数据按照新标签结构导出，XPath就无能为力，因为它没有构造节点的语法。
下面是一段典型XPath用法，在Java中借助DOM解析器执行：
import javax.xml.parsers.*;
import org.w3c.dom.*;
import javax.xml.xpath.*;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse("books.xml");
XPath xpath = XPathFactory.newInstance().newXPath();
// 选取所有计算机类书籍标题
String expr = "/library/book[category='computer']/title/text()";
String result = (String) xpath.evaluate(expr, doc, XPathConstants.STRING);
System.out.println(result);
XQuery的FLWOR与构造能力
XQuery被设计为一种功能完整的查询语言，官方全名是XML Query Language。它内建了XPath作为表达式子集，但增加了类似SQL的FLWOR（For、Let、Where、Order by、Return）语句。通过 for 遍历节点序列，用 where 筛选，用 order by 排序，最后在 return 中直接写出新的XML结构。这种能力让XQuery可以一条语句完成抽取加变形，而不依赖宿主语言拼字符串。
除了FLWOR，XQuery支持自定义函数、模块导入、条件表达式 if-then-else，还能处理多个输入文档。例如要把书店里贵于三十元的书生成带折扣价的新清单，XPath做不到，而XQuery在return里写 <discounted>{ $b/title, $b/price*0.9 }</discounted> 即可直接造出元素。大括号在XQuery里表示切换回表达式上下文，这是和纯标签文本最大的区别。
以下示例展示用XQuery从图书文件挑书并重塑结构：
for $b in doc("books.xml")/library/book
where $b/price > 30
order by $b/price descending
return
<expensive>
<name>{ data($b/title) }</name>
<cost>{ $b/price * 0.9 }</cost>
</expensive>
可以看到，XQuery脚本本身就是合法XML外壳加嵌入表达式。它既能当查询用，也能当轻量转换工具用。很多支持XQuery的数据库（如eXist-db）直接把这种脚本存为视图，前端拿到的就是已经排好版的数据。
实际选型与性能对照
从执行模型看，XPath引擎通常只做单遍树遍历，没有中间结果物化开销，因此在简单取值时延迟极低。XQuery处理器要先展开FLWOR管线，涉及序列化和节点构造，启动成本略高。但在需要多步关联、分组统计时，XQuery把逻辑下沉到查询层，避免了把整棵DOM树搬进Java或Python再手搓循环，总体IO和内存反而更省。
团队分工上，如果只做爬虫抽取字段、JUnit里断言某个节点存在，写XPath最直观，也方便运维人员肉眼读。若要做报表聚合、把旧系统XML导成新 schema，XQuery一处写好，后续改标签名不用动主程序。要注意XQuery标准分1.0和3.1，部分老引擎不支持高阶函数，写之前先确认运行环境。
| 维度 | XPath | XQuery |
|---|---|---|
| 定位 | 节点寻址语言 | 查询与构造语言 |
| 循环 | 无 | FLWOR支持 |
| 输出新XML | 不能 | 能 |
| 学习曲线 | 平缓 | 中等 |
综上，把XPath当作XQuery里的导航零件最合适。新手先练熟 //、[]、@ 等路径写法，再学XQuery的return造节点，就不会被层层大括号绕晕。两者互补，而非二选一。