🌐 前后端混合多语言方案
在中大型多语言系统中，简单的前端语言包往往无法满足所有场景，而后端全托管又容易带来维护复杂度。
本篇文章介绍一种更具实用性的 前后端混合国际化策略，基于 实现灵活而强大的国际化支持。
💡 为什么采用混合方案？
| 类别 | 示例 | 来源 | 说明 |
|---|---|---|---|
| 📍 | 按钮、菜单、提示 | 前端静态语言包 | 项目初始化时加载 |
| 📉 | 业务内容 | 接口返回语言字段 | 后端根据语言返回 |
🏗️ 项目结构与文件说明
🧩 初始化配置 i18n.ts
在项目入口文件 Eg: 文件引入
切换语言的 hooks
使用前端文案
使用后端语言字段
📦 按模块拆分语言包
原则: 小而美、模块独立、语义清晰、集中管理
- 业务文案模块化（可维护）
- key 命名规范化（可读性强）
- 系统级别的: 权限与认证相关、错误提示和状态反馈等放在 系统级别文件 中
- 统一级别的: 放在 中的文案包括：、、、、等。
- 业务级别: 放在对应的业务模块下面 Eg: 等等
📄 举个例子
⚙️ 语言包体积大时的优化方案：CDN + 命名空间按需加载
技术策略：
- 静态语言包放 CDN 将各语言下的各命名空间的 .json 文件放在 CDN 上，例如：
优势总结
- 📦 降低主包体积（语言包独立加载）
- ☁️ 静态资源部署灵活（CDN 加速全球访问）
- 配置 i18next 的 backend 插件 使用 支持按需加载命名空间：
如何使用
工作原理解析：
{{lng}}：语言 由 i18n.language 决定，例如 'zh_CN' 或 'en_US'
{{ns}}：命名空间 由 useTranslation('sys') 或 i18n.loadNamespaces(['sys']) 等代码中传入的命名空间决定。