Lingui.js 多语言方案中的请求级语言隔离实践

背景与问题场景

在现代Web应用开发中，服务端多语言处理常面临一个典型挑战：当多个请求并发处理时，全局语言设置可能导致竞态条件。以Lingui.js为例，传统用法中通过i18n.activate()切换语言时，若两个请求先后修改全局语言状态，可能导致前一个请求的语言环境被后请求覆盖。

典型问题场景如下：

1. 请求A设置语言为捷克语(cs)
2. 请求A开始执行耗时任务
3. 请求B在此期间设置语言为西班牙语(es)
4. 请求A继续执行时，实际使用的语言环境已被污染

核心解决思路

方案一：语言作用域隔离（理想化方案）

开发者最初设想的解决方案是通过创建显式的作用域来隔离语言环境：

i18n.scope({
  language: "cs"
}, ({ t }) => {
  return t`Welcome` // 保证在此作用域内始终使用捷克语
})

这种方案直观且符合编程直觉，但存在框架层面的实现复杂度。

方案二：运行时上下文隔离（推荐方案）

基于Node.js的异步上下文跟踪能力，结合Lingui的运行时配置模块化特性，可实现更优雅的解决方案：

1. 利用AsyncLocalStorage：Node.js内置的异步本地存储机制，可创建请求级别的上下文隔离
2. 自定义i18n实例：创建代理实例动态获取当前请求上下文中的语言设置
3. 配置运行时模块：通过runtimeConfigModule指定自定义实例替代默认实现

具体实现路径

1. 创建上下文管理器

// context.ts
import { AsyncLocalStorage } from 'async_hooks'
import { I18n } from '@lingui/core'

const storage = new AsyncLocalStorage<I18n>()

export function withI18nContext(i18n: I18n, callback: () => void) {
  storage.run(i18n, callback)
}

export function getCurrentI18n() {
  return storage.getStore()
}

2. 实现代理i18n实例

// custom-i18n.ts
import { getCurrentI18n } from './context'

export const i18nProxy = new Proxy({} as any, {
  get(_, method) {
    return (...args: any[]) => {
      const i18n = getCurrentI18n()
      if (!i18n) throw new Error('I18n context not initialized')
      return i18n[method](...args)
    }
  }
})

3. 配置Lingui运行时

// lingui.config.js
module.exports = {
  runtimeConfigModule: ['./custom-i18n', 'i18nProxy']
}

4. 中间件集成示例（Express）

app.use((req, res, next) => {
  const i18n = new I18n({ locale: detectLocale(req) })
  withI18nContext(i18n, next)
})

方案优势分析

1. 无侵入性：保持原有t宏的使用方式，无需修改业务代码
2. 高性能：利用Node.js原生机制，上下文切换开销极低
3. 框架无关：核心原理可适配任何Node.js Web框架
4. 可扩展性：可轻松扩展存储其他请求级元数据

注意事项

1. 确保在请求入口处正确初始化上下文
2. 异步操作需保持上下文传递（如async/await会自动保持上下文）
3. 对于非Node.js环境需采用其他隔离方案（如线程本地存储）

通过这种架构设计，开发者既能享受全局API的便利性，又能获得请求级别的语言环境隔离，有效解决了服务端多语言处理的并发安全问题。