你好！作为一名在 2026 年依然奋战在代码一线的开发者，我们深知技术的迭代速度。虽然现代前端框架（如 React, Vue, Svelte）已经让我们习惯了声明式的 UI 编程，但在网页抓取、端到端（E2E）测试以及 legacy 系统的维护中，精准定位 DOM 元素依然是一项核心技能。

在处理复杂的 DOM 结构时，CSS 选择器虽然流行，但 XPath 的逻辑处理能力和对树状结构的导航能力往往能解决那些令人头疼的选择难题。特别是在面对动态生成的 ID 或混淆过的类名时，XPath 就像是我们手中的瑞士军刀。

在这篇文章中，我们将深入探讨如何高效、稳健地使用 XPath 按类选择元素。我们不仅会回顾从最基础的语法到复杂的部分匹配，还会结合 2026 年的 AI 辅助开发理念，分享我们如何在现代开发工作流中运用这些技巧。让我们准备好终端和 IDE，一起开始这段探索之旅吧！

理解核心：XPath 与 HTML Class 属性

首先，让我们快速建立思维模型。XPath（XML Path Language）本质上是一种在 XML 或 HTML 文档树中进行导航的查询语言。这就好比我们在文件系统中使用路径查找文件，只不过这里的“文件”是网页上的节点。

而在 HTML 的世界里，class 属性不仅仅是样式的挂载点，它更像是一个语义标签。一个元素通常长这样：

  ...内容...

这里，INLINECODE2be45519 的值是 "card highlight featured"。在 CSS 中，INLINECODE0afb0aaf 足以选中它。但在 XPath 中，我们需要处理完整的字符串属性。这看似简单，但在实际的企业级项目中，如果缺乏策略，写出来的 XPath 可能会像纸糊的房子一样脆弱——页面结构微调或 CI/CD 环境发布了一个新版本，你的自动化脚本可能就崩了。因此，掌握正确的方法至关重要。

基础篇：精确匹配 Class

让我们从最基础的场景开始。当我们拥有稳定的静态页面，或者处于高度可控的测试环境中时，精确匹配是最快的选择。

#### 1. 选择具有特定类名的元素

XPath 使用方括号 INLINECODEeecbe7c4 来表示条件（称为谓语），使用 INLINECODE4d1751f3 符号引用属性。

基本语法：

//tag[@class=‘class-name‘]

代码示例：

假设我们有一个包含系统警告的 div：

  请检查您的输入。

我们可以使用以下 XPath 来精准选中它：

//div[@class=‘alert-danger‘]

解释：这里的 INLINECODEf8bd3fad 表示在文档中的任何位置查找 INLINECODE8216abfc 标签，方括号内的条件表示：“只选择那些 class 属性值完全等于 ‘alert-danger‘ 的 div”。注意是完全等于，这限制了它的灵活性。

#### 2. 绝对路径 vs 相对路径：关键区别

在我们最近的一个自动化测试重构项目中，我们发现 80% 的脚本失效都是因为使用了绝对路径。理解两者的区别是写出健壮代码的第一课。

绝对 XPath：

绝对路径从根节点（INLINECODEeff4cd9f）开始，层层遍历。它以单个正斜杠 INLINECODE590682b8 开头。

• 语法示例： /html/body/div[1]/div[2]/p
• 特点： 就像完整的家庭住址，包含每一层楼、每一扇门。
• 缺点： 极其脆弱。只要 UI 团队在 header 里加了一个 div，或者在侧边栏调整了顺序，这个 XPath 就会彻底失效。
• 适用场景： 除非你要找的是文档的根元数据，否则禁止使用。

相对 XPath：

相对路径以双斜杠 // 开头。它告诉引擎：“在文档的任何位置寻找符合条件的元素”。

• 语法示例： //div[@class=‘container‘]//p
• 特点： 更加灵活。它不关心元素在顶层的位置，只关心它本身的属性及其上下级关系。
• 适用场景： 这是 2026 年的标准做法，特别是在配合 Selenium 或 Playwright 时。

进阶篇：处理多类名与复杂匹配

随着 Web Components 和 Utility-First CSS（如 Tailwind）的普及，DOM 结构变得越来越复杂。一个元素可能同时拥有十几个类名，或者是带有哈希值的动态类名（如 style_btn__a1b2c）。这时候，单纯的“等于”就不够用了。

#### 3. 匹配包含多个 Class 的元素

HTML 允许一个元素有多个类，用空格隔开。假设我们有这样的按钮：

场景：

提交
取消

错误尝试：

//button[@class=‘btn active‘]

这会失败，因为属性的完整值是 "btn btn-primary active shadow-lg"，而不是 "btn active"。

正确做法：使用 INLINECODE3e8cc319 函数配合逻辑运算符 INLINECODE4066609a。

//button[contains(@class, ‘btn‘) and contains(@class, ‘active‘)]

解释：这个表达式非常强大。它告诉浏览器查找所有按钮元素，这些元素的 class 属性中既要包含 ‘btn‘ 字符串，也要包含 ‘active‘ 字符串。它不关心顺序，也不关心中间夹着 ‘btn-primary‘。这正是我们在处理 Tailwind CSS 或 BEM 命名法时的救星。

#### 4. 部分匹配与 Tokenization：不仅仅是 contains()

虽然 contains() 很好用，但它有一个潜在的风险：子串匹配。

实战中的陷阱：

假设我们要查找 class 为 "btn" 的按钮，但页面还有一个 class 为 "btn-group" 的容器。

  点击我

如果你使用 INLINECODEd8b83988，没问题。但如果你使用 INLINECODE1a846642，你会意外选中父容器 btn-group，这可能不是你想要的。

2026 年的高级解决方案：规范化 Token 匹配

为了解决这个问题，我们需要一种更严谨的方式来匹配被空格分割的单词。在 XPath 1.0 中，我们可以这样写：

//div[contains(concat(‘ ‘, normalize-space(@class), ‘ ‘), ‘ btn ‘)]

*解释：这个表达式看起来很复杂，但它的逻辑非常完美：

• normalize-space(@class)：首先把属性值中多余的空格压扁，变成标准的单空格格式。
• concat(‘ ‘, ..., ‘ ‘)：在字符串前后人为地加上空格。
• contains(..., ‘ btn ‘)：查找 " btn "（注意两边有空格）。

这确保了我们只匹配完整的单词 "btn"，而不会匹配 "btn-group" 中的 "btn"。在我们处理大型遗留项目时，这种写法极大地减少了误报率。*

实战演练：完整 HTML 案例与调试

光说不练假把式。让我们通过一个更完整的 HTML 示例来演练我们的技巧。

HTML 代码片段：

    
    
    
        .container { padding: 20px; }
        .highlight { color: red; }
    


    
    
    

    
    

        
欢迎来到测试页面
        
        
        

            
这是一段描述文字。
        

        

            
        
    

    
    

让我们来解决几个实战问题：
问题 1：选中所有带有 "card" 类的 div？

//div[contains(@class, ‘card‘)]

问题 2：精准选中既是 "card" 又是 "featured" 的元素？

我们需要结合逻辑运算符：

//div[contains(@class, ‘card‘) and contains(@class, ‘featured‘)]

问题 3：找到导航栏中处于激活状态的链接？

利用层级关系来缩小范围，这是提高性能的关键：

//nav[@class=‘main-nav‘]//a[contains(@class, ‘active‘)]

AI 辅助开发：2026 年的 XPath 写作之道

在 2026 年，我们不再仅仅依赖手动编写选择器。随着 Cursor、Windsurf 和 GitHub Copilot 等工具的普及，我们的工作流发生了质变。

1. 使用 "Vibe Coding"（氛围编程）生成 XPath

现在，当我们面对一个复杂的 DOM 结构时，我们通常会这样操作：

• 场景描述：我们在 IDE 中选中一个元素，然后向 AI 发出指令：“帮我为这个具有特定类名的按钮生成一个稳健的 XPath，要求使用 contains 函数以防止类名变动导致失效。”
• AI 生成：AI 会直接在编辑器中生成建议的代码，甚至附带解释。

2. LLM 驱动的调试

如果你的 Selenium 脚本因为找不到元素而报错，不要急着去翻文档。你可以把报错信息和 HTML 片段直接丢给 AI Agent（自主代理），它会自动分析：

• 是否是 iframe 导致的上下文切换问题？
• 是否是动态渲染的延迟问题？
• XPath 表达式是否存在语法错误？

示例 AI Prompt：

> "我有一个 XPath //div[@class=‘item‘]，但是在 Playwright 中无法选中新增加的列表项。帮我修改成能匹配以 ‘item-‘ 开头的类名的表达式。"

AI 建议的输出：

//div[starts-with(@class, ‘item-‘)]

这种交互方式让我们能够更专注于业务逻辑，而不是纠结于正则或语法细节。

最佳实践与性能优化：生产环境指南

在数百万次运行的自动化脚本中，一个低效的 XPath 可能导致测试套件的运行时间增加数倍。以下是我们总结的黄金法则：

1. 避免“索引依赖”和“万能选择器”

你可能会看到这样的写法：div[5]（选择第 5 个 div）。

千万不要在生产环境中这样做！ 除非那是表格里的具体行。在 UI 开发中，元素顺序经常变动。同时，避免使用 //div 这种不带任何条件的“万能选择器”，这会让浏览器遍历整个 DOM 树，造成巨大的性能开销。
2. 性能优化：越具体越好，但也要适度

INLINECODEcdccf3d7 会遍历页面上所有的 div。如果能限定范围，比如 INLINECODE1fd8b30c，就会快得多，因为它只在 content 容器内搜索。

• Bad: //div//div//div//a （层级过深，不仅慢而且极易断）
• Good: //div[@class=‘main-content‘]//a[contains(@class, ‘download‘)]

3. 善用相对路径与轴

除了 INLINECODEb0f336ba（后代），我们还可以使用 INLINECODEea1dd1fc（当前）、INLINECODEbe3439ab（父节点）或者 INLINECODE6d3ed39e（后续兄弟节点）。这在处理列表或表格行时特别有用。

例如，选中某段文字后面的紧邻的按钮：

//p[text()=‘产品 A‘]/following-sibling::button

这种基于关系的定位比依赖类名更稳定，因为文案通常比前端类名更难变动。

总结

通过这篇文章，我们不仅回顾了 INLINECODE98b82c57 的基础，还深入探讨了利用 INLINECODE77585b87 和逻辑运算符处理多类名、避免子串匹配的 Token 匹配法，以及如何在现代 AI 辅助工作流中高效编写 XPath。

掌握 XPath 按类选择元素，不仅仅是记住语法，更是培养一种对 DOM 结构的敏锐直觉。它赋予了我们绕过复杂层次结构的束缚，直接通过元素特征进行精准定位的能力。

下一步建议：

在你的下一个项目中，尝试结合使用 Puppeteer 或 Selenium，并配合 Cursor 等工具。当你遇到复杂的动态网页时，试着先手动写出 XPath，然后再让 AI 帮你优化。你会发现，这种“人类直觉 + AI 算力”的组合，正是 2026 年技术开发的极致效率所在。祝你在自动化和数据抓取的道路上越走越远！