XML文档的查询语言从XPath 1.0演进到XPath 2.0，不仅仅是版本号的变化，而是底层数据模型与表达式能力的全面重构。理解两者的差异，有助于在遗留系统与新标准之间做出合理的技术选型。
数据模型与类型系统的差异
XPath 1.0的数据模型相对简单，只定义了四种基础数据类型：节点集（node-set）、布尔值、数值和字符串。其中节点集是无序的节点集合，数值统一以双精度浮点处理，没有日期、时间等复杂类型的概念。这种弱类型设计让简单查询容易上手，但在处理结构化业务数据时，开发者必须借助XSLT或宿主语言完成类型转换与计算。
XPath 2.0采用了基于序列（sequence）的item模型，任何值都是零个或多个item的有序集合。item可以是节点，也可以是原子值，而原子值可绑定到XML Schema定义的各种类型，例如xs:date、xs:integer、xs:string等。这种强类型体系使得表达式在编译期就能发现类型不匹配的错误，也允许函数对不同类型的参数进行重载。
<!-- XPath 1.0 无法直接计算日期差，只能拿到字符串 -->
<xsl:value-of select="substring-before(order/date,'T')"/>
<!-- XPath 2.0 直接使用日期类型做运算 -->
<xsl:value-of select="xs:date(order/date) - xs:date('2023-01-01')"/>
表达式语法与逻辑控制能力
在XPath 1.0中，路径表达式是核心，逻辑处理严重依赖谓语（predicate）过滤，缺乏通用的流程控制结构。如果要根据条件返回不同结果，通常只能写多个select或使用XSLT的choose结构。例如筛选价格大于100且类别为书的节点，只能嵌套谓语，可读性随条件增多而下降。
XPath 2.0引入了if-then-else条件表达式，以及for、some、every等量化表达式，让纯XPath就能表达分支与循环逻辑。它还支持逗号分隔的序列构造，配合FLWOR风格的表达式，可以把原本需要在宿主语言里写的统计逻辑压缩成单行查询。下面示例展示如何用2.0语法按类别汇总金额。
//item[if (@category='book') then price*1.0 else price*0.9]
对比之下，1.0要实现同样的折扣逻辑，必须把判断放到外层样式表或代码中，XPath本身只负责取数。这种表达力差距在复杂报表场景下尤为明显。
函数库与操作符的扩展
XPath 1.0仅提供约二十七個核心函数，覆盖字符串、节点、布尔等基础操作，且没有正则表达式支持。字符串处理只能靠contains、substring等原始函数，面对复杂清洗任务力不从心。
XPath 2.0将函数库大幅扩充，并划分为基础函数和基于XML Schema的函数。新增了matches、replace、tokenize等正则函数，以及avg、max、min、sum等聚合函数，还有current-date、day-from-date等日期组件提取函数。操作符也增加了except、intersect等节点集运算，以及值比较与通用比较的区分。以下代码演示2.0中如何过滤并聚合。
sum(//product[matches(name,'^A')]/price)
| 能力 | XPath 1.0 | XPath 2.0 |
|---|---|---|
| 正则匹配 | 不支持 | matches/replace |
| 聚合计算 | 需外部语言 | sum/avg内置 |
| 条件分支 | 谓语模拟 | if-then-else |
命名空间与兼容性处理
XPath 1.0对命名空间的处理较为原始，路径中的前缀必须和上下文绑定的命名空间一致，且不支持通配前缀的灵活书写。当XML带有多个命名空间时，写错前缀就会导致空结果，排错困难。
XPath 2.0明确了元素与属性名的EQName结构，支持通过命名空间URI直接引用，而不依赖前缀。它还引入了默认命名空间变量，配合xpath-default-namespace可减少重复前缀。虽然这提升了严谨性，但也意味着旧版依赖前缀隐式绑定的脚本，在迁移时需显式声明空间，否则会解析失败。
从实践角度看，若系统仍运行在仅支持XPath 1.0的老旧XML解析器上，应尽量避免复杂逻辑下沉到查询层；新项目则可利用2.0的类型与函数优势，显著降低代码体积。
总体来看，XPath 2.0在类型安全、表达力和函数丰富度上全面超越1.0，代价是学习曲线更陡且解析器要求更高。技术选型时，应综合评估运行环境与查询复杂度，而非盲目追新或守旧。