为何我的XPath返回null？含tbody的路径失效原因咨询

这是个很常见的前端解析坑，核心原因在于浏览器会自动补全HTML结构，但HtmlAgilityPack严格遵循原始页面源码解析：

• 当你在XMLQuire或者浏览器开发者工具里测试XPath时，浏览器的HTML解析引擎会按照HTML规范，自动为没有显式写<tbody>的<table>元素补全<tbody>标签。也就是说，哪怕页面源码里<table>直接包含<tr>，浏览器工具里展示的DOM结构会变成<table><tbody><tr>...</tr></tbody></table>，所以你的//table[contains(@class,'top-feature')]/tbody/tr/td/a能正常匹配到内容。
• 但HtmlAgilityPack加载页面时，会完完整整保留原始HTML的结构。如果Kijiji的目标页面源码里，<table class='top-feature'>下面直接是<tr>元素（根本没有写<tbody>），那你的XPath里强行加了<tbody>自然找不到对应节点，返回null。

你后来改用的//table[contains(@class, 'top-feature')]/tr/td[@class='description']/a能生效，就是因为它直接匹配了原始HTML里<table>下的<tr>元素，和你用多层循环遍历的逻辑完全一致。

实用小技巧 #

如果不确定页面结构里是否存在<tbody>，可以通过以下方式验证和兼容：

1. 用DOM.DocumentNode.OuterHtml输出解析后的完整HTML，查看table的子元素结构
2. 用更灵活的XPath兼容两种情况：//table[contains(@class,'top-feature')]//td[@class='description']/a（双斜杠匹配任意层级的子元素）或者//table[contains(@class,'top-feature')]/*/td/a（匹配table下的直接子元素，不管是tbody还是tr）

内容的提问来源于stack exchange，提问作者Mark Denom