Next.js集成i18next国际化时如何处理多语言API响应

响应语言类型校验方法 #

• 校验请求头传递的语言标识：打开浏览器开发者工具的Network面板，选中对应接口查看Request Headers，确认Accept-Language字段值和用户当前选中的语言code一致（比如意大利语对应it/it-IT、简体中文对应zh-CN），前端切语言后没同步更新请求头的语言值，是最常见的返回英文的原因。
• 校验响应头的语言标识：符合HTTP多语言规范的服务端，会在Response Headers里返回Content-Language字段，字段值即为当前响应内容实际使用的语言code，直接读取该字段就能快速判定服务端返回的语言是否符合预期。
• 直接校验响应体文案：如果服务端未返回Content-Language字段，直接核对响应体中的提示类字段内容即可，比如选中意大利语时，操作成功提示仍返回英文"Operation succeeded"而非意大利语对应文案，即可判定服务端未正确返回目标语言内容。

全链路处理逻辑 #

• 前端请求拦截层处理：在全局请求拦截器中统一注入语言请求头，不要在单个业务接口中重复配置，避免漏传。以常用的axios请求库为例，配置代码如下：

axios.interceptors.request.use(config => {
  // 从全局状态/本地存储中读取用户当前选中的语言code，未选择时默认传英语
  const currentLang = localStorage.getItem('site_lang') || 'en'
  config.headers['Accept-Language'] = currentLang
  return config
})

• 服务端语言解析层处理：和后端对齐逻辑即可，要求服务端优先解析请求头中Accept-Language的语言值，匹配服务端预置的多语言包返回对应文案，匹配不到对应语言时走默认兜底逻辑，同时在响应头中返回Content-Language字段标识当前响应语言。不要在前端硬编码翻译服务端返回的提示文案，后续维护成本会极高。
• 前端响应拦截层处理：全局响应拦截器不需要做文案转译，只需要直接读取响应体中的提示字段做弹窗/提示展示即可，可以加一层简单的校验逻辑：如果响应头返回的Content-Language和当前用户选中语言不匹配，打控制台日志或者上报埋点，方便后续排查配置问题。

常见配置踩坑 #

• 前后端语言code必须提前对齐统一枚举，比如前端意大利语传it，后端语言包意大利语的key是it-IT，就会出现匹配失败自动fallback到英语的问题。
• 用户选择的语言配置要做持久化存储，避免页面刷新后语言配置重置为英语，导致请求头携带错误的语言值。
• 优先使用标准Accept-Language请求头传递语言参数，不要把语言值拼在url、query参数或者自定义非标准头里，绝大多数后端框架默认支持解析该标准头，不需要额外做适配。

内容的提问来源于stack exchange，提问作者dev007