直接结论：定位 HTML 页面元素时，通常优先选择基于稳定属性的 CSS 选择器，因为它语法简洁、浏览器支持广且便于维护；需要按文本筛选、从子节点反向查找祖先、处理复杂兄弟关系或查询 XML 时，XPath 更合适。如果自动化框架提供按角色、标签或文本定位的专用 API，应优先评估这些 API，而不是强制只在 XPath 和 CSS 选择器之间二选一。
选型结论：XPath 与 CSS 选择器该怎么选？
优先选择 CSS 选择器的情况
目标元素具有稳定的 id、class、data-testid 或其他语义属性，并且查询主要依赖标签、属性及常规父子结构时，CSS 选择器通常是更直接的方案。例如，[data-testid='submit-order'] 能清楚表达“定位提交订单按钮的测试标识”。
优先选择 XPath 的情况
查询需要依据可见文本定位元素、从已知子节点回溯到祖先节点、精确处理前后兄弟关系，或者目标文档是 XML 时，XPath 通常更有表达力。例如，可以先找到文本为“订单详情”的标题，再通过 ancestor:: 轴定位它所在的业务区域。
不应只比较两者的情况
Playwright、Testing Library 等工具提供按角色、标签或文本定位的高级 API。这类定位方式通常更符合用户实际操作和可访问性语义，也可能具备自动等待、严格匹配等框架能力。选型时应把框架原生定位器与 XPath、CSS 选择器一起比较。
基础定义对比：XPath 与 CSS 选择器是什么？
CSS 选择器的定义
CSS 选择器是一套按照元素名称、ID、类名、属性以及元素结构匹配 HTML 或 XML 节点的语法。它最初用于确定 CSS 样式应应用到哪些元素，也被浏览器 DOM API、自动化测试工具和网页解析库用于元素查询。例如，article.product-card > a.detail 表示匹配商品卡片中作为直接子元素的详情链接。
XPath 的定义
XPath 是一种在 XML 文档树中选择节点并计算节点相关值的查询语言，也常被用于查询 HTML DOM。它可以根据节点名称、属性、文本、位置和上下文关系筛选目标，并通过祖先、后代及兄弟轴进行正向或反向查询。例如，//article[@data-type='product']//a 表示选择指定文章节点下的所有链接。
两者的核心区别
CSS 选择器侧重通过元素特征和结构关系进行匹配，常见 HTML 查询写法更短；XPath 把文档视为节点树，支持更丰富的路径、文本条件和轴关系。两者都能完成大量元素定位任务，但表达范围、运行环境和维护成本并不完全相同。
定位能力对比：属性、文本与节点关系
属性定位对比：CSS 通常更简洁
对于稳定属性，CSS 和 XPath 都能准确定位。CSS 可写为 [data-testid='submit-order']，对应的 XPath 是 //*[@data-testid='submit-order']。这种场景下，CSS 写法更短，也更容易被熟悉前端开发的团队成员理解。
文本定位对比：XPath 的通用表达能力更强
XPath 可以使用 text()、contains() 或规范化空白后的文本条件筛选节点。标准 CSS 选择器通常不能直接按照元素的文本内容匹配；某些自动化框架虽然支持文本定位，但那是框架扩展能力，不等同于通用 CSS 语法。文本可能受到翻译、空白、动态数据和文案调整影响，因此不宜把易变文本作为唯一定位依据。
正向结构查询对比：两者都能胜任
查找父元素下的子元素或后代元素时，两者通常都能清晰表达。CSS 可使用空格或 > 组合符，XPath 可使用 / 或 //。如果只是查询常见 HTML 层级，CSS 往往更易读。
反向与兄弟关系对比：XPath 更成熟
XPath 原生提供 ancestor::、parent::、preceding-sibling:: 和 following-sibling:: 等轴，适合从已知节点反向或横向查找。CSS 的 :has() 能覆盖部分父级和关系查询，但能否使用取决于目标浏览器、自动化框架或解析库的支持情况。
XML 与命名空间对比：XPath 更适合专业查询
对于配置文件、接口返回的 XML、SOAP 文档或含命名空间的节点树，XPath 通常更符合查询需求。CSS 选择器也可能被部分 XML 解析器支持，但命名空间处理和复杂节点关系查询往往不如 XPath 直接。
工程实践对比：可读性、稳定性与性能
可读性对比：简单查询偏向 CSS，复杂关系偏向 XPath
基于稳定属性的短 CSS 选择器通常最容易阅读。需要表达复杂节点关系时，XPath 可以避免编写额外遍历代码，但过长的 XPath 也会增加审查和排错成本。选择器若无法在一眼内说明定位意图，可以考虑拆成多个查询步骤或增加稳定的业务标识。
稳定性对比：定位依据比语法类型更重要
选择器是否稳定，主要取决于它依赖的页面信息，而不是它属于 CSS 还是 XPath。基于 data-testid 等稳定属性的写法通常比依赖位置的选择器可靠。应避免多层 nth-child()、连续位置索引和 /html/body/... 形式的绝对 XPath，因为页面插入一个容器或列表项就可能导致定位失效。
性能对比：应在目标环境中测量
“CSS 一定比 XPath 快”并不是适用于所有环境的结论。查询性能取决于表达式、文档规模、浏览器、解析库和自动化框架。在多数网页自动化流程中，网络、页面渲染和等待条件通常比单次元素查询更耗时。只有在定位已被确认是瓶颈时，才需要使用真实页面和目标工具进行基准测试。
兼容性对比：核对具体实现而非只看标准
浏览器 DOM API、自动化框架和服务端解析库对 CSS 特性及 XPath 版本的支持存在差异。使用 :has()、复杂伪类、XPath 函数或命名空间查询前，应检查目标工具的版本和文档，并通过实际用例验证。
场景对比：自动化测试、网页抓取与 XML 查询
网页自动化测试：框架定位器与稳定属性优先
先评估角色、可访问名称、标签等框架原生定位方式；需要直接编写选择器时，再以稳定属性的 CSS 选择器作为默认起点。只有在文本条件或反向节点关系无法清晰表达时，才采用 XPath。动态价格、时间和多语言文案不适合作为唯一定位条件。
网页抓取：根据字段与标签的关系选择
从重复列表项中提取标题、链接和价格时，CSS 选择器通常足够直观。如果页面只有字段标签可作为识别依据，例如需要从“产品编号”文本找到相邻值，XPath 的文本和兄弟轴可能减少后续遍历代码。使用前要确认抓取库支持的 CSS 级别和 XPath 版本。
复杂 DOM：以准确表达和可维护性为先
复杂 DOM 并不意味着必须使用 XPath。如果元素具有稳定属性，CSS 仍然可能是最简单的方案；如果查询依赖祖先或兄弟关系，XPath 通常更合适。若两种写法都非常复杂，应考虑拆分查询、缩小作用域，或推动页面增加稳定标识。
XML 查询：通常优先 XPath
XPath 专门面向节点树查询，适合 XML 的元素、属性、文本和命名空间处理。对于需要频繁查询 XML 的系统，XPath 通常比 CSS 选择器具有更清晰的语义和更完整的工具支持。
选型方法与权衡
第一步：确认目标文档与执行工具
先判断目标是 HTML 还是 XML，再确认浏览器、自动化框架或解析库实际支持哪些语法。标准定义中的功能不一定已经被当前执行环境完整实现。
第二步：寻找最稳定的定位依据
优先级通常可以设为专用测试属性、稳定业务属性、可访问性语义、稳定 ID，再到类名和结构关系。易变文本、动态类名、深层位置以及绝对路径应放在较低优先级。
第三步：比较表达长度与维护成本
如果 CSS 能用一个清晰的属性选择器完成定位，就没有必要改用更长的 XPath；如果 CSS 需要复杂关系组合，而 XPath 能直接描述节点关系，则 XPath 更容易维护。选型目标是让定位意图清晰，而不是追求团队全局只使用一种语法。
第四步：验证唯一性、稳定性与等待行为
在真实页面中检查选择器是否只命中预期元素，并测试加载延迟、列表变化和容器调整后的结果。自动化测试还应使用框架提供的等待机制，避免通过盲目延时掩盖定位或页面状态问题。
常见问题
XPath 与 CSS 选择器可以混用吗？
可以。项目可以根据定位需求混用两者，但同类页面或组件宜遵循一致的定位优先级和约定。
CSS 选择器能按文本内容查找元素吗？
标准 CSS 选择器通常不能直接按元素文本匹配。部分测试框架提供文本定位 API，但这属于框架能力，不是通用 CSS 语法。
XPath 是否总比 CSS 选择器慢？
不是。性能取决于表达式、文档规模和执行环境，应在真实页面及目标工具中测量。多数情况下，定位稳定性和可维护性更值得优先考虑。
CSS 的 :has() 能完全替代 XPath 吗？
不能完全替代。:has() 可以处理部分关系查询，但 XPath 在文本筛选、祖先与兄弟轴以及 XML 查询方面仍更完整，且具体支持情况取决于执行环境。
网页自动化应该优先使用 XPath 还是 CSS 选择器？
具有稳定属性时通常优先使用简洁的 CSS 选择器；需要文本条件或复杂反向关系时使用 XPath。若框架提供按角色、标签或文本定位的原生 API，也应优先评估。
总结
HTML 元素具有稳定属性时，优先考虑简洁的 CSS 选择器；需要文本筛选、祖先或兄弟关系查询以及 XML 处理时，优先考虑 XPath。选择时还要核对工具兼容性，避免绝对路径、位置索引和易变文案，并在真实页面中验证定位的唯一性与稳定性。