i18n 可维护性关键在翻译键集中可追溯、语言切换不破坏状态、格式化逻辑统一可控；需杜绝键分散硬编码、拼接调用、多实例、原生 locale API 等问题。
直接看 i18n 相关代码是否可维护、可测试、可切换，而不是先问“用了 i18n 库没”。用没用库不重要，关键在于翻译键、语言切换、格式化逻辑这三块是否散落在组件里、硬编码在模板中、或靠手动改 HTML 文件来切语言。
翻译键是否集中且可追溯
常见错误是每个组件自己定义 key，比如 login.submitBtn 和 auth.submitButton 实际指向同一文案，但没人知道它们重复了。更糟的是键名含中文（登录按钮）或带空格（header title），导致 JSON 解析失败或无法做静态分析。
- 检查所有
t()、$t()或类似调用，确认其参数是否全为字符串字面量，而非拼接变量（t('user.' + type)）——后者无法被提取工具识别 - 验证翻译文件是否按模块/页面组织，且无孤儿键（即代码里已删、JSON 里还留着的 key）
- 运行
npm run extract-i18n类脚本（如 vue-i18n-locale-message 的 extract），看能否完整导出所有键；若大量缺失，说明键分散在v-html、innerHTML或内联 style 中
语言切换是否破坏状态或触发重渲染
典型症状是切换语言后表单数据清空、滚动位置丢失、或路由跳转——说明 locale 被当作 prop 传入子组件，而非通过 context / provide 注入；或者 i18n 实例被多次 new，导致响应式失效。
- 检查
i18n是否全局唯一实例（Vue 用createI18n，React 用useI18nhook，而非每次 render 都new I18n()） - 确认语言切换是否触发整页 reload（
window.location.reload()）——这是最廉价也最伤体验的“解决方案” - 观察控制台是否有
[intlify] Not found key报错，这类警告往往掩盖真实问题：键存在但作用域不对（如异步组件未等 i18n ready 就渲染）
日期/数字/货币格式是否依赖浏览器 locale
用 toLocaleDateString() 直接格式化，表面看没问题，实际埋雷：不同浏览器对同一 locale 的输出不一致（如 Safari 对 zh-CN 的年月日顺序处理异常），且无法 mock 测试。
立即学习“前端免费学习笔记（深入）”；
- 检查是否所有格式化调用都经过
i18n提供的$d、$n方法，而非原生 JS API - 验证
numberFormats和dateTimeFormats配置是否覆盖全部目标语言，尤其注意阿拉伯语（ar）需 RTL 支持、印度语系（hi/bn）需本地数字字符 - 运行测试时强制设置
navigator.language = 'ja'，看页面是否仍能正确显示「2026年7月7日」而非「2026/07/07」
真正难清理的不是漏翻的文案，而是那些“看起来能跑”的格式化逻辑和状态耦合——它们不会报错，但会让新语言上线变成一场灰度事故。债务不在翻译文件里，而在你调用它的那几行代码的上下文里。
