线上HTML国际化是否生效，关键在于验证三类节点是否同步更新：语义化文本容器、属性文本、动态插入内容，并用Playwright校验多语言渲染结果及RTL、复数、日期格式等真实场景。
线上 HTML 国际化是否生效，不能只看 document.documentElement.lang
改了 lang 属性但文字没变、标点间距错乱、屏幕阅读器读错——这说明国际化根本没跑通。真正要监控的不是“设没设”，而是“有没有被正确应用”。document.documentElement.lang 只是起点，不是终点。它不触发任何翻译逻辑，也不影响已有 DOM 的渲染行为。
必须检查三类节点是否同步更新：
-
<p lang="zh-Hans">、<h2 lang="ja">等语义化文本容器：每个含自然语言文本的标签都应显式带lang，且值与当前语言包一致 -
<input placeholder="Search">、<img alt="logo">等属性文本：仅靠data-i18n不够，必须有对应后缀如data-i18n-placeholder、data-i18n-alt - 动态插入内容（AJAX 弹窗、分页表格行）：这些 DOM 不会自动翻译，需在插入后立即调用翻译函数，否则
data-i18n仍是原始键名
用 Playwright 拦截并断言多语言渲染结果
Playwright 是目前最适配国际化巡检的端到端工具——它能真实模拟用户访问路径，支持多语言 header 注入、页面快照比对、DOM 属性批量校验。
关键实操点：
立即学习“前端免费学习笔记（深入）”；
- 启动时通过
launch({ locale: 'zh-CN' })或请求头Accept-Language: zh-Hans控制服务端/客户端语言协商起点 - 用
page.locator('p[lang="zh-Hans"]').count()验证关键段落是否带正确lang值，而非只查根节点 - 对
input元素，必须分别断言：await input.getAttribute('placeholder')和await input.getAttribute('data-i18n-placeholder')是否匹配预期语言值 - 避免用
textContent直接比对中文，因空格、全角标点、换行易导致误判；推荐用正则模糊匹配核心词（如/欢迎.*登录/.test(text)）
巡检任务里最容易漏掉的三个硬伤
工程化巡检不是“跑通就行”，而是要覆盖真实失效场景。以下三点一旦忽略，90% 的国际化问题会逃过检测：
-
RTL 布局未触发：阿拉伯语或希伯来语切换后，
dir="rtl"没加、CSS 逻辑属性（margin-inline-start）没生效、表单 label 与控件顺序颠倒——这些不会报 JS 错，但用户完全无法操作 -
复数形式错乱：英文
"1 item"/"2 items"在俄语或阿拉伯语中可能有 4–6 种变体，若语言包只提供单数键，所有复数场景都会回退到默认文案或显示 key 名 -
日期/数字格式未走 Intl：直接拼接
new Date().getFullYear() + '年'会导致日语用户看到“2026年”（正确应为“2026年”但字体、宽度、标点规则不同），必须用Intl.DateTimeFormat('ja-JP').format(new Date())
死链扫描必须和国际化路径耦合
LinkChecker 类工具默认只扫 URL，但国际化站点的链接往往带语言前缀（/zh/about、/en/contact）。如果巡检只从 / 开始爬，会漏掉所有非默认语言页面。
正确做法是把语言路由作为输入源：
- 生成语言路径清单：
['/zh/', '/ja/', '/en/', '/ar/']，逐个作为 LinkChecker 的起始 URL - URL 提取器必须配置为解析
<a href="/zh/product?id=123">中的相对路径，并自动补全语言前缀，否则跨语言跳转会变成 404 - 对
<link rel="alternate" hreflang="zh-Hans" href="/zh/">标签做存在性校验——缺失意味着搜索引擎无法识别多语言关系，SEO 会塌方
languageChanged 事件，必须在 insertAdjacentHTML 或 append() 后立刻调用翻译函数——这个动作没法靠全局 MutationObserver 自动补全，得写进每个业务模块的插入逻辑里。 
