Selenium嵌套XPath匹配li文本报NoSuchElementException的解决方法

这个异常和动态参数拼接逻辑无关，核心是你写的XPath文本匹配规则和实际渲染的DOM结构不匹配，具体有两类常见场景：

• 首尾空白字符干扰：绝大多数前端下拉组件渲染选项时，会因为代码缩进、样式预留空格等原因，让li标签内的文本前后带上换行、空格、制表符等不可见字符，比如实际DOM中文本为 dog 或者\ndog\n，此时text()='dog'的完全精确匹配规则会匹配失败。而你用序号li[1]选择时不需要校验文本内容，只要li节点存在就能命中，所以可以正常运行。
• 文本不在li的直接文本节点中：很多组件会把选项文本嵌套在span、a等子标签内，比如DOM结构为<li><span>dog</span></li>，此时text()只会取li标签的直接子文本节点（这里是空值或者空白），不会递归读取子标签内的文本，自然无法匹配到目标选项。
  你在控制台删除/li段后能选中ul节点，只能证明ul之前的XPath路径是正确的，无法验证li节点的文本匹配逻辑是否有效。

将XPath替换为兼容空白字符、支持递归读取子节点文本的写法即可，使用normalize-space()处理文本可以自动去除首尾空白、合并中间多余空格，用.代替text()可以匹配当前节点下所有层级的文本内容：

String optionXpath = String.format("//*[@id='xyz']/div[2]/ul/li[normalize-space(.)='%s']", selectElement);
WebElement xyz = driver.findElement(By.xpath(optionXpath));

如果存在下拉选项渲染延迟的问题，可以补充显式等待，等目标选项可点击后再操作，避免偶发的元素找不到问题：

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement targetOption = wait.until(ExpectedConditions.elementToBeClickable(By.xpath(optionXpath)));
targetOption.click();

不建议直接用contains()做模糊匹配，否则当选项存在puppy_dog、dog_toy这类相似值时会出现误命中，normalize-space(.)的写法属于精准匹配范畴，适配绝大多数下拉选择场景。

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