XPath中text()仅匹配直接子文本节点，无法处理嵌套、空白或模糊匹配；应优先使用normalize-space()或string()进行内容级匹配。
XPath 选择包含特定文本的节点，核心在于正确理解 text() 的语义和局限性——它只匹配**直接子文本节点**，不包含后代文本、不处理换行缩进、也不支持模糊匹配。想精准定位，得结合函数和轴来补足。
text() 只匹配直属文本，不是“节点内含文字”
text() 是一个节点测试，返回当前节点的**直接子文本节点集合**。比如：
Hello World!
其中 div/text() 只返回两个文本节点："Hello " 和 "!"，"World" 属于 span 的子文本，不在 div 的 text() 结果中。
所以 //div[text()="Hello World!"] 永远不匹配——因为实际文本被拆分且含嵌套元素。
用 string() 或 normalize-space() 做内容级匹配
要判断整个元素“看起来显示什么文字”，应改用 string()（返回合并后的全部文本）或更实用的 normalize-space()（自动去首尾空格、合并中间多余空白）：
-
//div[normalize-space() = "Hello World!"]→ 匹配上面例子 -
//button[normalize-space() = "提交"]→ 忽略按钮内换行、空格、tab -
//p[contains(normalize-space(), "错误")]→ 模糊查找含关键词的段落
定位含部分文本的节点：contains() + normalize-space() 是黄金组合
单独用 contains(text(), "...") 极易失效（因 text() 返回多节点，contains 只接受单字符串）。安全写法是：
- ✅
//a[contains(normalize-space(), "登录")] - ✅
//label[contains(., "用户名")]（.等价于string(.)） - ❌
//span[contains(text(), "确认")]（若 span 有子标签或前后空格，大概率失败）
高级技巧：按文本位置筛选，用 position() 或索引配合 text()
当需选“第2个文本子节点为XXX”的罕见场景（如解析纯文本结构化数据），才真正需要 text() 索引：
-
//td/text()[2]→ 获取 td 的第二个直接文本节点（常用于表格中带换行的单元格） -
//p[text()[1] = "注意："]→ 要求第一个直属文本正好是“注意：”，后面可跟其他元素
注意：这种写法脆弱，仅适用于已知 HTML 结构高度可控的场景（如自动生成报告页）。
基本上就这些。记住关键点：text() 是“精确切片”，string() 和 normalize-space() 才是“人眼所见”。别硬刚 text()，绕一步用 . 或 normalize-space()，90% 的问题当场解决。
