先记住这个答案
推荐优先 getByRole 本质在于它强调从用户与无障碍 API 角度识别控件。定位器基于元素在可访问性树中的角色及可访问名称，而非 DOM 结构或样式，因此更符合 Playwright 低脆弱性目标。使用它常能提前暴露语义缺口，同时避免 CSS 链或 XPath 索引断裂。
- 角色定位把测试锚定在用户语义层
- CSS 类与 XPath 索引因重构易失效
- 结构不稳定时应改用语义测试协议
从 DOM 结构到可访问性语义
浏览器会将元素映射为可访问性树，角色与名称是树中关键属性。例如 <button> 自动获得 button 角色，<input type="checkbox"> 获得 checkbox。使用者可直接用这些语义概念描述目标，而不必关心它是用 div、span 还是改过 ARIA 的真正控件。
名称计算遵循 ARIA 规范，优先级是 aria-labelledby、aria-label、内部文本等，与 CSS 类名或 DOM 结构层级无关。相比之下 CSS 选择器如 .btn 只知道类名，XPath 如 //form/div/button 编码层级索引，任何版面调整都可能修改这些属性。
一次样式重构，定位器并未改动
假设样式重构：开发者将 <a class="submit">提交</a> 的类名改为 btn-primary 并调整了布局，元素标签与角色仍是 link。若测试使用 page.locator('a.submit') 会因类名变化而失败；而 getByRole('link', { name: '提交' }) 仍能命中，因为可访问名称与角色未变。
若按 XPath 写 //a[contains(@class,'submit')] 同样失败。角色与名称完全稳定，类名变化只影响 CSS 选择器。这种情况下语义定位器无需同步修改，降低了维护成本。当然，如果后续把元素改为 button 且未保留 role="link"，getByRole('link') 将失败，从而暴露语义变化，这有助于团队审查用户交互的改变。
语义缺失时的替代方案
getByRole 在面对无语义标签时作用有限：多个复选框都叫“选项”，或一段显示纯数字但无任何可访问名称的 span 都会使定位器无法保证唯一。此时可叠加 .filter({ hasText: ... }) 或改用 getByText，更合理的是补上 aria-label。
对非语义容器，官方建议使用 getByTestId 显式测试契约，而不是用 XPath 硬编码结构。XPath 在 Shadow DOM 中无法穿透，而角色定位器可以，这让语义路线覆盖更广。测试逻辑应优先靠近用户视角，而非 DOM 内部顺序。
容易答错的地方
- 角色定位只是规范执行工具
- 它确实用于定位，但依据浏览器可访问性 API 工作，能够早期发现缺少文字或角色滥用。测试失败可能映射产品缺陷，而非仅是选择器失效。
- CSS 定位任何时候都不好
- 不是说不可以用，而是结构不固定时脆弱。对稳定控件用类选择器也能工作，但角色提供了额外语义验证，且重置成本低，因此官方推荐它。
面试官还会怎么问？
可访问名称如何计算？
按 ARIA 规范：优先 aria-labelledby，然后 aria-label，再考虑 label 元素与内部文本。Playwright 直接使用浏览器计算结果。若名称变化，需修改定位器参数。
什么时候 getByText 优先于 getByRole？
当元素无显式角色，且文本就是用户看到的内容时，例如普通文本或某个 span，使用 getByText 更直观。Role 定位适合交互或标题等语义元素。
getByRole 会不会拖慢测试？
需要计算可访问名称，但开销远小于网络延迟，且 Playwright 自动等待与重试会重新解析。性能影响可忽略，稳定性收益更大。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。