必须在CI/CD构建阶段将国际化校验设为可失败步骤，通过静态扫描HTML/JSX中未包裹的字符串、校验多语言JSON键一致性，并确保CI环境与生产环境的locale映射、文件结构完全一致。
CI/CD 中怎么触发 HTML 国际化文本的自动检查
不能靠人工翻页核对，必须在构建阶段就捕获缺失翻译或硬编码字符串。核心是把「国际化校验」变成一个可失败的构建步骤，而不是发布后才发现 lang="zh" 页面里混着英文 "Submit"。
推荐用 grep + 正则做轻量级扫描，配合项目实际 i18n 方案（如 i18next、react-i18next 或原生 Intl）定制规则：
- 检测所有未包裹在
t()、useTranslation()、gettext()等函数调用中的字面量字符串（需排除注释、URL、class 名等误报） - 检查 HTML 文件中是否存在未通过
data-i18n、data-locale或属性绑定渲染的静态文本 - 对
en.json、ja.json等翻译文件做键一致性校验：确保每个语言包都包含login.submit这类 key，缺一则 CI 报错
为什么不能只测 JSON 翻译文件完整性
光比对 JSON 键是否齐全，漏掉了最常见问题：HTML 模板里写了死字符串，压根没走 i18n 流程。比如：
<button>Save changes</button>——它完全绕过了
t("save_changes")，JSON 再全也没用。
所以必须双轨并行：
立即学习“前端免费学习笔记（深入）”；
- 静态扫描 HTML/JSX/Templates：找未被 i18n 函数包裹的 ASCII 字符串（长度 ≥ 3，且不在
href、src、class属性中） - 运行时快照测试（可选）：用 Puppeteer 启动不同
lang的页面，截取文本节点，与预期翻译表比对——适合关键路径，但慢、不稳定，不建议放主 CI
CI 脚本里怎么写可维护的校验逻辑
别写一堆 shell 正则硬匹配。用现成工具封装更稳：
- 前端项目：加
eslint-plugin-i18n-json检查 JS/TS 中字符串调用合规性；用jsonlint验证各语言 JSON 格式+key 对齐 - 纯 HTML 项目（无构建工具）：用
html-i18n-checkerCLI 扫描.html文件，配置白名单（如id="version-number"不校验） - GitLab CI / GitHub Actions 中，把校验命令设为独立 job，失败即中断 pipeline：
script: npm run check-i18n && npm run validate-locales
容易被忽略的兼容性陷阱
很多团队卡在「测试通过但线上还是出错」，问题常出在环境差异：
-
en-US和en-GB被当两个 locale 处理，但共享同一份en.json—— CI 校验时若只比对en.json，会漏掉en-GB特有项（如"colour"） - HTML 中
lang属性值（如lang="zh-Hans"）和翻译文件名（zh.json）不一致，导致 fallback 失败，但 CI 不报错——得在脚本里显式校验映射关系 - 某些构建工具（如 Vite）默认不复制
locales/目录到 dist，测试时读的是开发目录下的 JSON，而线上跑的是空目录——CI 必须模拟真实 dist 结构再校验
真正难的不是写检测逻辑，而是让 CI 看到的文件结构、locale 映射、运行时行为，和生产环境严丝合缝。差一个 public/ 前缀，就可能让整个校验失效。
