管理后台数据国际化方案，JSON扩展键的实践与优势

在构建现代化管理后台时，数据国际化已成为一项核心需求。与界面文案（如「保存」「操作成功」）可通过语言包文件解决不同，数据文案（如菜单名称、字典项等）由于存储于数据库中，无法直接使用传统语言包机制。本文将围绕三种主流解决方案展开讨论，并重点介绍一种基于 JSON 扩展键的创新实践。

三种方案对比分析

独立翻译表：通用性最强但成本高昂

独立翻译表的核心思想是将翻译内容作为数据单独存储，典型结构如下：

这种方案的优势在于极高的通用性，适用于任何表、字段和语言组合。但在管理后台场景下，其成本主要体现在四个方面：读取侧需要额外 JOIN 操作导致性能下降；孤儿数据问题需要额外维护；维护入口分散导致操作复杂；兜底逻辑散落各处难以统一管理。

每语言一列：查询效率高但扩展性差

另一种常见做法是在每张表中为每种语言增加一个字段，例如 name_zh、name_en 等。这种方式的优点是查询效率极高，译文直接存储在行内，且每列都有完整的类型约束。然而，当需要新增语言时，必须对所有相关表进行 DDL 操作，导致系统整体扩展性较差。

主列 + JSON 扩展键：创新实践的平衡之选

我们选择的第三种方案是在现有主列基础上，通过 JSON 扩展键存储多语言译文。以菜单为例，sys_menu 表的数据结构如下：

{

"activePath": "/sys/user",

"i18n": {

"zh-CN": "用户管理",

"en-US": "User Management"

}

}

这种方案的主要优势在于：加语言只需更新 JSON 数据，无需修改表结构；读取时译文随主数据一同返回，无需额外查询；零迁移特性确保老库升级后行为一致；兜底逻辑集中在一个工具函数中。

实践案例：菜单管理的全链路落地

技术实现细节

在技术实现层面，我们采用了以下关键措施：

• 数据库：使用 MySQL 5.7 的 text 类型存储 JSON 数据，通过统一的工具函数进行读写校验
• 接口：采用变量传递机制，后端不参与语言协商
• 前端：通过 applyMenuI18n 函数实现菜单名称的动态替换
• 兜底逻辑：集中在一个工具函数中处理未翻译情况

总结与展望

通过对比分析，我们可以看到，主列 + JSON 扩展键的方案在管理后台数据国际化场景下具有显著优势。它不仅解决了传统方案的成本痛点，还提供了更高的灵活性和可维护性。未来，我们将继续优化这一方案，并探索在更多业务场景下的应用可能性。