XPath中的sum()函数用于计算节点集中所有节点的数值总和，是XML数据统计中最常用的聚合函数之一。与编程语言中需要循环遍历节点再逐个累加不同，XPath的sum()只需一条表达式即可完成求和操作，并且结果直接以数值类型返回。它的处理流程是把每个选中节点的字符串值取出，按照XPath数值转换规则解析成数字，然后依次累加。这个机制让开发者可以专注表达业务逻辑，而不必关心底层的数据遍历细节。
sum()函数的基本语法与工作原理
sum()函数的语法结构非常简洁，它通常只接收一个参数，即待求和的节点集。这个节点集可以由绝对路径、相对路径或带谓词的过滤表达式生成。函数内部会对节点集中的每一个节点执行字符串值转换，再将得到的字符串按XPath的数值规则解析为数字。解析成功后的值会被逐一累加，最终返回一个整数或浮点数。如果节点集为空，sum()会返回数字0，这是XPath 1.0规范中明确规定的行为。
为了更直观地说明这个计算过程，下面给出一个典型的XML订单文档。文档中每个item节点包含商品名称和价格，价格以纯数字字符串的形式存储在price节点中。
<order>
<item>
<name>机械键盘</name>
<price>399</price>
</item>
<item>
<name>无线鼠标</name>
<price>199</price>
</item>
<item>
<name>显示器</name>
<price>1499</price>
</item>
</order>
要对上述文档中所有商品的价格求和，可以直接使用表达式 sum(/order/item/price)。求值器会依次读取三个price节点的文本内容，把它们分别解释为数字399、199、1499，然后相加得到结果2097。这里的路径表达式精准地选中了所有price节点，sum()函数则负责完成剩余的类型转换与累加，整个过程无需额外的循环代码。
需要注意的是，sum()的参数必须是节点集，不能直接传入字符串或数字字面量。虽然某些XPath实现可能对参数类型比较宽容，但按照标准写法，应当传入路径表达式或变量绑定的节点集。若传入的节点集中包含非数值文本，sum()会对该节点返回NaN（Not a Number），并且整个求和结果也会变成NaN，这一点在实际使用中一定要特别留意。
典型应用场景与表达式组合
在实际的XML数据处理中，sum()函数经常与谓词过滤、多级路径和属性筛选配合使用。例如在电子商务系统中，可能需要统计某个分类下所有已上架商品的总销售额，这时路径表达式会结合多个条件来缩小求和范围。下面的示例展示了几个常见的组合写法，它们分别处理了按数量、按状态、按语言属性过滤后求和的需求。
// 统计购买数量大于等于2的商品总价 sum(//item[quantity >= 2]/price) // 统计状态为已上架的商品总价 sum(//product[@status='online']/price) // 统计中文图书的总定价 sum(//book[@lang='zh']/price)
第一个表达式中的谓词 [quantity >= 2] 会在求值前过滤掉数量小于2的item节点，只对满足条件的price节点执行求和。这种把过滤逻辑内嵌到路径中的写法，既保证了数据准确性，又提升了表达式的可读性。第二个表达式利用属性值匹配来筛选商品状态，第三个表达式则根据语言属性区分不同版本的图书，这些场景都属于sum()函数的高频用法。
除了单层求和，sum()也可以应用于多层级的嵌套结构。例如在一个包含多个部门的公司XML中，每个部门下都有若干员工的薪资节点，要计算全公司所有员工的薪资总额，可以使用 sum(//department//salary)。双斜杠表示任意层级的匹配，无论入职信息嵌套多深，都能被这条路径覆盖。这种特性让sum()在处理不规则或深层次XML数据时显得尤为灵活。
在某些业务场景中，还需要对求和结果进一步做数学运算，比如计算折扣后的实际付款金额。sum()返回的数字可以直接参与加减乘除，例如 sum(//item/price) * 0.8 表示在原价总和基础上打八折。由于sum()返回的是标准数值类型，它也可以继续作为参数传给XPath中的其它数值函数，比如 round()用于四舍五入，floor()用于向下取整。
使用sum()函数需要避开的几个坑
sum()函数虽然使用方便，但如果不清楚它的类型转换规则，很容易在程序运行时得到意外结果。第一个常见问题是节点文本中包含非数字字符，比如价格字段存成了"399元"或"￥199.00"。按照XPath的数值转换规则，这类带有货币符号或中文单位的字符串无法被完整解析为数字，最终会导致该节点求和时返回NaN，整个sum()表达式的结果也随之变成NaN。因此在书写求和路径前，应尽量确保目标节点的文本符合纯数字格式。
第二个容易踩坑的地方是空节点集的返回值问题。XPath 1.0规定sum()作用于空节点集时返回0，这让很多开发者误以为求和操作永远会得到一个数字。但问题在于，当路径表达式因为拼写错误或数据缺失而意外选不到任何节点时，sum()同样返回0，这会掩盖路径写错的事实。比如原本想统计上个月的销售额，却因为字段名拼写错误导致路径匹配不到节点，计算结果变成0，表面上看起来似乎是“没有销售额”，实际却是查询逻辑有误。因此使用sum()时，建议先单独验证路径表达式选中的节点数量是否符合预期。
第三个需要注意的细节是字符串与数字的隐式转换。sum()内部虽然会做数值解析，但它解析时使用的是XPath的字符串转数值规则：字符串开头允许有空格，随后必须是一个合法的数字，数字后面不能再跟非数字内容。以文本"42abc"为例，它不会被解析为42，而会被解析为NaN。反之，如果文本是"42"或"42.5"，则能正确转换。理解这个规则有助于排查数据源中格式不规范的字段。
// 在XPath中手动检查节点文本是否为数字 sum(//price[number(text()) = number(text())]) // 这种写法利用NaN不等于自身的特性，过滤掉非数字节点后再求和
上面的示例展示了一个过滤非数字节点的技巧：number(text())被调用后，如果文本无法转为数字会得到NaN，而NaN不等于自身。因此谓词 number(text()) = number(text()) 只对能成功转为数字的节点返回true。通过这样的组合表达式，即使数据源混入了脏数据，sum()仍然可以给出可用的结果。不过这种巧妙的写法牺牲了一部分可读性，建议在代码中配合注释说明。
与其它XPath聚合函数的分工对比
XPath提供了一组聚合函数，除了sum()之外，还有count()用于统计节点数量，min()和max()用于求最值，avg()用于求平均值。这些函数各自解决不同的问题，在实际使用中经常组合出现。下表列出了它们的主要区别和使用场景，方便开发者根据业务需求做出选择。
| 函数 | 作用 | 典型返回值 | 适用场景 |
|---|---|---|---|
| sum() | 数值求和 | 数字 | 总价、总金额、总数量 |
| count() | 统计节点个数 | 整数 | 订单数、商品种类数 |
| min() | 返回最小值 | 数字 | 最低价格、最早日期 |
| max() | 返回最大值 | 数字 | 最高薪资、最大库存 |
| avg() | 返回平均值 | 数字 | 平均消费、平均评分 |
从上表可以看出，sum()关注的是总量，count()关注的是个数，两者在统计口径上有本质区别。例如统计一个订单的条目数可以用 count(/order/item)，但要计算订单金额就必须用 sum(/order/item/price)。在实际报表系统中，这两个函数常常配合使用，通过sum()除以count()得到客单价或平均每项金额，从而对业务数据进行更深入的分析。
另外需要注意的是，min()、max()和avg()在XPath 1.0中并不存在，它们是在XPath 2.0及后续版本中才加入的。也就是说，如果你的运行环境只支持XPath 1.0，那么聚合运算只能依赖sum()和count()这两个基础函数。例如当需要求最大值时，必须借助排序表达式或额外编写比较逻辑来实现。反观sum()和count()，因为它们从XPath 1.0起就被定义，几乎兼容所有主流XML解析库和浏览器内置的XPath引擎。
与编程语言中的聚合函数相比，XPath的sum()还有一个独特优势：它不需要预先指令数据的存储格式。无论节点是嵌套在多层元素之下，还是分布在文档的不同区域，只要路径表达式能准确匹配到目标节点，sum()就能正确完成求和。因此，在编写XML数据清洗脚本或自动化测试断言时，优先使用sum()往往比使用通用编程语言的处理方式更加简洁高效。