// 查找全树任意位置匹配节点，效率低；/ 仅查当前节点直接子节点，效率高。应优先用 / 定位再局部 //，避免全树遍历。
// 是从整个文档中任意位置查找匹配的节点，不关心层级关系；/ 是从当前上下文节点的直接子节点中查找，只匹配下一层。
定位范围不同
//div 表示查找文档中所有 div 元素，无论嵌套多深；/div 只匹配当前节点的直接子元素中叫 div 的那个（如果当前是根节点，就等价于 /html/body/div 这类绝对路径的首层）。
例如在
text
中：
- //span → 找到 text
- /body/div/p/span → 也能找到它（精确路径）
- /span → 找不到，因为 span 不是根节点的直接子节点
// 会触发全树遍历
使用 // 时，XPath 引擎通常需要扫描整棵 dom 树，逐个检查每个节点是否满足条件。节点越多、嵌套越深，耗时越长。
/ 则只检查当前节点的子节点列表，时间复杂度接近 O(n)，n 是子节点数量，效率高得多。
能用 / 就别用 //
如果结构已知且稳定，优先写明确路径，比如 /html/body/main/article/h1 而不是 //h1。
常见优化方式：
- 用 / 定位到某一层后，再用 // 局部搜索（如 //article//h1 比 //h1 快）
- 配合属性缩小范围（如 //div[@class=”content”]//p 比 //p 更快）
- 避免 //*[text()=”xxx”] 这类无索引、需文本比对的写法
浏览器和解析器的影响
现代浏览器（chrome、firefox）对 // 做了一定优化，比如提前剪枝或缓存，但底层仍是深度优先遍历；而 / 对应的 child:: 轴基本是常数时间操作。
在 xml 解析库（如 lxml、Saxon）中，// 的性能差距更明显，尤其文档大、命名空间多时。
基本上就这些。// 灵活但慢，/ 快但要求结构清晰。实际写 XPath 时，先想能不能用 / 锁定范围，再局部用 //，效果通常更好。