i18next 怎么初始化配置？resources/命名空间/插件集成指南

i18next 初始化配置是前端国际化的核心环节。i18next.init() 接收一个配置对象，最关键的几个选项：lng 设置当前语言，fallbackLng 指定翻译缺失时的回退语言，resources 直接内联翻译资源，ns 和 defaultNS 管理命名空间拆分。React 项目需要通过 initReactI18next 插件注入 i18next 实例，否则 useTranslation hook 无法工作。语言检测用 i18next-browser-languagedetector，可以按 querystring → cookie → localStorage → navigator 的顺序探测用户语言偏好。大型项目推荐用 i18next-http-backend 按需加载翻译文件，避免把所有语言的 JSON 打包进主 bundle。interpolation.escapeValue 在 React 中要设为 false，因为 React 自带 XSS 转义。开发阶段开启 debug: true 可以在控制台看到翻译 key 缺失的警告。

追问

resources 内联和 HTTP 后端加载怎么选？

小项目（2-3 种语言、翻译总量不超过 50KB）直接内联 resources，启动快、无额外请求。中大型项目用 i18next-http-backend，翻译文件按语言和命名空间拆成独立 JSON，首屏只加载当前语言的 translation 命名空间，其他页面切换时再按需加载。注意 HTTP 后端是异步的，init() 返回的 Promise resolve 之前组件渲染会拿到空翻译，需要配合 React Suspense 或 useTranslation 的 ready 状态处理。

命名空间怎么划分比较合理？

常见做法是 translation（公共文案）、common（按钮/标签等高频复用）、validation（表单校验提示）、errors（错误码映射）。按页面拆命名空间（如 home、profile）也可以，但粒度太细会增加维护成本——每个命名空间对应一个 JSON 文件，翻译人员要在多个文件间切换。实际项目中 3-6 个命名空间基本够用，超过 10 个就该考虑合并了。

fallbackLng 配置不当会导致什么问题？

fallbackLng 默认是 "dev"，翻译缺失时 key 会直接显示在页面上。如果设为 "en"，中文用户看到的是中英混杂的界面——部分 key 有中文翻译，缺失的回退到英文。更隐蔽的问题：fallbackLng 设为数组 ["zh", "en"] 时，i18next 会按顺序查找，key 查找链变长影响性能。建议设为项目的主要语言（比如 "zh"），开发时靠 debug: true 发现缺失的 key，而不是依赖 fallback 兜底。

init() 的回调写法和 Promise 写法有什么区别？

回调写法 i18next.init(config, (err, t) => {...}) 在 i18next 早期版本就支持，t 函数在回调里直接可用。Promise 写法 await i18next.init(config) 更直观，但要注意 HTTP 后端加载时 Promise resolve 不代表所有命名空间都加载完了——如果配置了 partialBundledLanguages，部分命名空间可能是异步加载的。React 项目一般用 initReactI18next 中间件，内部处理了等待逻辑，不需要手动处理回调。