XPath在C#中操作XML文档时是最常用的查询手段，但表达式里只要有一个字符写错，SelectSingleNode就可能安静地返回null，连一句异常信息都不给你。更让人头疼的是，有些表达式在浏览器插件或在线测试工具里运行得好好的，复制到C#代码里就彻底失效，排查方向很容易跑偏。实际上，绝大多数XPath查询失败都集中在几个固定原因上：语法细节理解有偏差、命名空间没有正确处理、引号转义出了问题。下面把这些高频错误逐一拆解，并配上可以直接照做的调试方法。

位置索引与路径写法：最容易写错的语法细节

刚接触XPath的C#开发者，几乎都写过//order[0]这种表达式。C#的数组索引从0开始，但XPath的位置谓词从1开始，[0]在XPath里属于无效条件，查询结果为空，而且不会抛出任何异常。要取第一个节点必须写//order[1]，取最后一个用last()，倒数第二个写成last()-1。这个差异没有任何编译期提示，只能靠记住规则，否则排查半天也想不到是索引基数的问题。

XmlDocument doc = new XmlDocument();
doc.Load("orders.xml");
// 错误写法：XPath位置索引从1开始，[0]永远取不到节点
XmlNode wrong = doc.SelectSingleNode("//order[0]");  // 返回null
// 正确写法：取第一个order节点
XmlNode first = doc.SelectSingleNode("//order[1]");
// 取最后一个节点
XmlNode last = doc.SelectSingleNode("//order[last()]");
// 取倒数第二个节点
XmlNode secondLast = doc.SelectSingleNode("//order[last()-1]");
// 取前三个节点，注意小于号在表达式中直接书写即可
XmlNodeList top3 = doc.SelectNodes("//order[position() <= 3]");

另一个高频错误是路径起始符号的误用。以/开头的绝对路径从文档根节点开始逐级匹配，而//表示在整个文档范围内递归查找所有后代节点。如果XML结构嵌套较深，用/root/orders/item这种写法必须保证每一级的名称完全一致，任何一级写错都会让结果为空。还要特别注意XPath对节点名称严格区分大小写，<Order>和<order>是两个完全不同的标签，编译器不会给出任何提示。拿不准层级关系时，先用//item把所有同名节点捞出来，观察它们的实际路径，再回头改写精确路径，比凭印象硬写可靠得多。

谓词部分还有几个容易混淆的点：//后面不能直接跟谓词，必须先有节点测试部分；position()和裸数字写法在同级范围内含义相同，但在复合表达式中优先级表现不同，复杂条件下显式写position()更清晰。此外，@符号用于匹配属性，漏写它会去匹配子元素而不是属性，这也是属性查询返回null的常见原因之一。

命名空间：查询返回null的头号元凶

如果XML文档的根元素上带有xmlns属性，直接用//entry查询几乎必然返回null。这不是bug，而是XPath 1.0规范的设定：表达式中没有前缀的节点名，只会匹配不属于任何命名空间的元素。而一旦XML声明了默认命名空间，文档里所有元素实际上都归属于那个命名空间URI，尽管它们表面上看不到前缀。于是无前缀的表达式和带命名空间的元素永远对不上号，查询结果自然为空。很多Atom订阅源、SVG文件、WSDL文档都带默认命名空间，这个问题在实际项目中出现频率极高。

// 假设feed.xml内容如下：
// <feed xmlns="http://www.w3.org/2005/Atom">
//   <entry>
//     <title>新版本发布</title>
//   </entry>
// </feed>
XmlDocument doc = new XmlDocument();
doc.Load("feed.xml");
// 直接查询返回null，因为entry实际属于默认命名空间
XmlNode fail = doc.SelectSingleNode("//entry");
// 正确做法：注册命名空间并绑定自定义前缀
XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
nsmgr.AddNamespace("atom", "http://www.w3.org/2005/Atom");
XmlNode ok = doc.SelectSingleNode("//atom:entry", nsmgr);
// 不确定命名空间时的临时方案：local-name绕过命名空间
XmlNodeList all = doc.SelectNodes("//*[local-name()='entry']");

解决这个问题的标准做法是使用XmlNamespaceManager注册命名空间，给URI绑定一个自定义前缀，然后在表达式中使用这个前缀。有一点需要特别说明：前缀本身不需要和XML文档里声明的前缀一致，真正参与匹配的是前缀背后的URI字符串，两者必须一字不差。如果URI抄错一个字符，查询照样返回null且没有任何提示，所以排查命名空间问题时，第一件事就是把URI和原文档逐字符比对。

在不确定文档命名空间结构、或者只想临时取数据时，可以用local-name()函数绕过命名空间匹配。它只比较节点的本地名称，完全忽略命名空间，写法简单但有两个代价：查询会遍历更多节点导致性能下降，同时可能误匹配其他命名空间下的同名元素。临时调试用它没问题，正式代码里还是老老实实注册命名空间更稳妥。

引号嵌套与大小写陷阱

C#字符串和XPath表达式都涉及引号，两层引号叠在一起极易出错。基本原则是：XPath里的字符串字面量可以用单引号或双引号包裹，但要和C#字符串外层的引号错开。属性值本身含单引号时，XPath层面改用双引号包裹；反之亦然。如果值里两种引号都有，就得借助concat函数拼接，写法虽然繁琐，但这是XPath 1.0下唯一规范的做法。引号配对错误通常会直接抛出XPathException，报错信息里会指出表达式的解析位置，比安静返回null好排查得多。

// 属性值包含单引号：XPath字面量改用双引号包裹
string xpath1 = "//user[@name=\"O'Brien\"]";
// 属性值包含双引号：XPath字面量改用单引号包裹
string xpath2 = "//book[@title='C#实战指南']";
// 值里两种引号都有：用concat函数拼接
string xpath3 = "//user[@name=concat('O', \"'\", 'Brien')]";
// contains区分大小写，匹配不到大写内容
// 用translate把属性值统一转成小写再比较
string keyword = "abc";
string xpath4 = "//user[contains(translate(@name, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), '" + keyword + "')]";

除了引号，函数的大小写行为也常被忽略。contains、starts-with都严格区分大小写，contains(@name, 'abc')匹配不到属性值为ABC的节点。XPath 1.0没有内置的小写转换函数，需要用translate把字符逐个映射成小写再做比较，写起来长但逻辑简单。另外，text()取的是节点的文本子节点，和直接用节点本身做字符串比较，在元素包含嵌套标签时结果可能不同，遇到取值不对的情况，可以分别试试//item/text()和//item两种写法。

实用调试技巧：快速定位失效的表达式

遇到查询返回null时，最有效的手段是把长表达式拆成几段逐段验证。先查根节点，确认能取到；再追加一级路径，看结果是否仍为空；从哪一段开始取不到节点，问题就锁定在那一段的名称或谓词上。用SelectNodes配合返回集合的数量做判断，比单纯判断null能获得更多信息，数量为0和数量为3但被谓词过滤成0，指向的问题完全不同。

XmlDocument doc = new XmlDocument();
doc.LoadXml(xmlString);
XPathNavigator nav = doc.CreateNavigator();
// 第一步：确认根节点的真实名称
Console.WriteLine("根节点：" + doc.DocumentElement.Name);
// 第二步：逐段验证，缩小出错范围
XPathNodeIterator iter = nav.Select("/root");
Console.WriteLine("root数量：" + iter.Count);
iter = nav.Select("/root/orders");
Console.WriteLine("orders数量：" + iter.Count);
// 第三步：输出文档开头，检查隐藏的命名空间声明
string head = doc.DocumentElement.OuterXml;
Console.WriteLine(head.Substring(0, Math.Min(200, head.Length)));

其次要善用OuterXml输出实际加载的文档结构。有些XML文件开头带有BOM、XML声明或者意料之外的空白，肉眼在编辑器里看不出来，输出到控制台后立刻现形。还可以用doc.DocumentElement.Name确认根节点的真实名称，避免大小写或隐藏前缀导致的误判。如果文档很大，只输出前两三百个字符就能看到根元素和命名空间声明，足够定位大部分问题。

最后提醒一点：在线XPath测试工具的结果只能参考，不能作为最终依据。部分工具默认忽略命名空间，或者实现了XPath 2.0的函数，这些差异都会造成工具里能跑、C#里不能跑的假象。排查时以.NET运行时的实际行为为准，写一个最小的控制台程序单独验证表达式，比在业务代码里反复改动再重启调试的效率高得多。

常见错误速查表

把前面提到的内容汇总成一张速查表，遇到问题时可以先对号入座，再深入排查：

总的来说，XPath查询出错时先看文档有没有命名空间，再检查索引基数和引号配对，最后用逐段验证的方式缩小范围，绝大多数问题都能在几分钟内定位。养成把复杂表达式拆短、关键查询写单元测试的习惯，后期维护XML相关代码时会轻松很多。