Testing-Library：container.querySelector与getByXX的差异及场景疑问

先明确：核心差异根本不是性能，而是测试理念、健壮性和调试体验的本质区别，下面具体拆解：

核心差异 #

• 测试视角完全不同
  getByXX/queryByXX系列方法是从用户视角出发设计的：比如getByText('提交')是找用户能看到的文本，getByRole('button')是按用户可感知的交互角色定位，完全贴合Testing-Library「像真实用户一样测试组件」的核心原则。而container.querySelector('button.submit-btn')是从DOM结构视角出发，依赖元素的标签、类名、选择器——这些都是用户不会关心的细节。

• 测试健壮性天差地别
  用getByXX的测试，哪怕组件内部DOM结构重构（比如把<button class="submit-btn">改成<div role="button" class="new-btn">），只要用户看到的内容、能触发的交互没变，测试依然能通过。但用querySelector的话，只要DOM结构的细节（类名、标签层级）一改，测试立刻失效，后期维护成本极高。

• 调试体验差距明显
  getByXX找不到元素时，会抛出非常清晰的错误提示：比如告诉你当前页面有哪些匹配的文本元素、或者为什么没有符合条件的角色元素，帮你快速定位问题。而querySelector找不到元素只会返回null，你得自己去翻DOM结构排查问题，效率低很多。

• 天然支持无障碍检查
  getByRole、getByLabelText这类方法，本身就遵循WCAG无障碍标准，用它们写测试的同时，相当于顺便验证了组件的无障碍可用性。querySelector完全做不到这点，甚至可能写出依赖非无障碍DOM结构的测试。

应用场景差异 #

优先用getByXX/queryByXX的场景 #

• 绝大多数业务组件测试：只要是验证用户可见的内容、可触发的交互，比如按钮点击、文本渲染、表单输入，都应该优先用这些方法，保证测试的健壮性和用户行为一致性。

适合用container.querySelector的场景 #

• 测试非用户可见的内部DOM元素：比如组件内部用于布局的隐藏节点、仅给JS逻辑用的辅助DOM（比如用于计算尺寸的隐藏div），这些元素用户完全感知不到，测试它们的结构时用querySelector没问题。
• 底层DOM操作类库的测试：如果你测试的是一个专门操作DOM的工具库（比如DOM节点拖拽、动态生成DOM的库），核心逻辑就是操作DOM结构本身，这时候用querySelector更直接，因为测试的目标就是DOM结构的正确性。
• 极端特殊的兜底场景：比如某些复杂的DOM结构，确实无法通过getByXX系列方法定位（比如需要依赖非常复杂的CSS选择器组合），这时候可以临时用querySelector，但尽量少用，毕竟会降低测试的健壮性。

内容的提问来源于stack exchange，提问作者leon.s