直接用 data-test-id 定位并显式校验文案内容最可靠，因 lang 属性不保证文本已渲染，而国际化测试本质是验证目标语言文本是否真实可见于 DOM。
直接用 data-test-id 定位 + 显式校验文案内容，比任何基于 lang 属性、aria-label 或 XPath 文本匹配的方案都更稳。国际化测试不是“测语言切换动作”，而是“验证目标语言的文本是否真实出现在 DOM 中且可见”。
为什么不能用 lang 属性做断言依据
lang 是 HTML 元素的声明性属性，它不保证对应语言的文本已加载或渲染完成。常见误判场景：
- 页面刚切到
zh，但翻译 JSON 还在fetch中，<html lang="zh">已写入，而所有<label>仍是英文 —— 此时断言lang成功，但实际 UI 未生效 - SSR 渲染时服务端写了
lang="en"，客户端水合后 JS 切成zh，但部分 DOM 节点未重绘，lang值已更新，文案却滞后 -
[lang="zh"] .form-label这类 CSS 选择器只控制样式（如字体），不参与文案替换逻辑，无法作为功能正确性的证据
怎么安全地校验多语言文案
核心原则：绕过“语言状态”，直击“最终渲染结果”。操作要点：
- 给每个待翻译的 DOM 元素加唯一
data-test-id，例如<label data-test-id="login-username-label"></label> - 用
page.locator('[data-test-id="login-username-label"]').textContent()（Playwright）或cy.getByTestId("login-username-label").invoke("text")（Cypress）取值 - 显式断言内容等于预期字符串：
expect(text).toBe("用户名")，而非expect(text).toContain("user") - 对 placeholder、error message 等动态文本，同样加
data-test-id并单独定位校验，不要依赖input[placeholder]属性抓取
自动化脚本里怎么模拟语言切换
别依赖浏览器自动识别 navigator.language，它不可控、不可重置。真实可行的做法：
立即学习“前端免费学习笔记（深入）”；
- 启动浏览器时注入语言偏好：
chromium.launch({ args: ['--lang=zh-CN'] })（Playwright）；Cypress 需通过Cypress.config('chromeWebSecurity', false)+ 自定义请求头伪造Accept-Language - 前端提供调试接口（如全局函数
window.__setLocale('ja')），测试脚本调用后触发翻译刷新，再等待文案变更 - 避免点击语言切换按钮后“等 1 秒”——改用
locator.textContent()的重试机制，直到返回非空且符合目标语言的字符串 - 如果后端返回多语言选项（如下拉菜单），确保测试用例覆盖
Accept-Language: fr-FR请求头下的响应数据，而非只测前端 JS 切换
容易被忽略的三个断裂点
国际化测试崩得最突然的地方，往往不在主流程：
- 日期/数字格式化字段（如
<input type="date">）在不同 locale 下会显示不同占位符或解析规则，但data-test-id无法覆盖 —— 必须用Intl.DateTimeFormat().resolvedOptions().locale辅助断言 - 异步加载的语言包失败时，页面可能 fallback 到英文，但控制台无报错、网络面板里 200 成功 —— 需在测试中主动 mock
fetch拦截，验证错误态 UI - React/Vue 组件内使用
v-t或{t('key')}时，若 key 不存在，默认渲染 key 字符串（如显示 "login.password"），这种“假成功”必须靠文案断言提前暴露
