面对一个登录表单，Playwright 的 getByLabel、getByPlaceholder、getByText 之间应如何按优先级选择？

语义绑定机制与匹配范围

getByLabel 解析的是控件与标签之间的显式关联：<label for="email"> 或 <label> 包裹控件。浏览器将其暴露为 accessible name，getByLabel 直接复用这一语义映射，因此即使页面 CSS 或布局变化，只要标签文案不变即可命中。这点与辅助技术的感知一致，可靠性有明确标准。

getByPlaceholder 只读取输入控件的 placeholder HTML 属性，该属性原本是设计用来展示输入示例，不是正式标识。加载后它随值输入逐渐消失，且可被重复或与其他控件共享。与 label 相比，它缺少唯一的语义上下文，因此只能退而求其次。

登录表单的实际定位决策

假设 DOM 为 <label for="username">用户名</label><input id="username" placeholder="请输入邮箱"> 且页面上另有文本“用户名不可用”。此时用 getByText('用户名') 会同时匹配 label 和警告文本，产生严格模式冲突；而 getByLabel('用户名') 干净地定位输入框，或 getByPlaceholder('请输入邮箱') 也可。工程约束是 label 始终存在，所以选择 getByLabel。

如果表单是快速原型，仅 <input placeholder="密码"> 而没有 label，则只能降级用 getByPlaceholder。但应注意 placeholder 作为提示不应承载关键信息，位置受样式影响但 API 稳定。在该场景中，getByText('密码') 会误选页脚版权中的“密码安全”段，所以绝不靠它定位。

失效条件与处理代价

getByLabel 的绑定失效发生在 label 的 for 指向不存在 id、或控件被移动到 label 之外且未加 for 时。此时控件远离可见标签，但仍可能靠 placeholder 提示。国际化场景下 label 文案从“密码”变为“Password”，硬编码的 getByLabel('密码') 会断裂，这与 getByText 同样受翻译影响，但前者的断裂点是单点易修改，后者可能因任意文本而命中多个元素。

getByPlaceholder 会因产品上调整 placeholder 内容而失效，例如“请输入邮箱”改为“Email”。而 getByText 除国际化外，还有动态文本拼接：如页面显示“欢迎，张三”，getByText('欢迎') 是子串匹配也可能命中，但当用户切换区或加载状态导致文本变化，会立刻无匹配。防止这些需用 exact: true 或正则，并限定在容器内，但这仍不改变输入的语义缺失问题。

容易答错的地方

认为 getByText 能定位输入框

输入框的文本值是其 value 属性，不构成元素的文本内容，getByText 无法看到当前值；它只能匹配元素本身包含的文本（如 label、按钮等），因此用它定位输入框常落空或误选其它元素。

认为 placeholder 与 label 等价

两者来源不同：label 通过 for 或包裹关联，是控件的正式名称；placeholder 只是提示，缺省不会传给表单，且在输入后消失。同时存在时优先 label，placeholder 只在完全无 label 时才作为后备。

面试官还会怎么问？

把知识连起来