浅析 iGIX 多语列的实现

iGIX 的多语列基于 Embedd 实现的 JPA 国际化持久化方案，简化业务开发国际化多语的存储。本文描述了一个在使用 Spring Data JPA 进行业务开发时，如何高效、优雅地解决数据库国际化多语存储的痛点问题。

01 痛点暴击

还在给每张业务表手写 N 个语言字段？

· 产品名：name_zh、name_en、name_ja…

· 分类名：category_zh、category_en…列爆炸、PO 爆炸、Mapper 爆炸，需求一改，全员加班。国际化成了“国际坑”。

02 官方正统解法为何失灵？

JDK 的 ResourceBundle 离数据库太远；MyBatis 手写 XML 可维护性噩梦；Hibernate 静态映射只能 1 字段 1 列，动态列？官方没给答案。于是我们把目光投向 Hibernate 最隐秘的扩展点——ImplicitNamingStrategy。

03/ 核心思想

“把多语字段折叠成一个嵌入式属性，运行时让 Hibernate 自己找到带后缀的列。”

04/ 三大件组成

① @Embeddable 类 CAFMultiLanguageColumn 内置 cafMlcchs / cafMlcen / cafMlccht / cafMlcpt / cafMlces 五个私有字段，统一前缀 cafMlc。提供 getValue(lang) / setValue(value) / getValues() 等 API，业务代码完全像操作 String。

② 自定义命名策略 CAFImplicitNamingStrategy 继承 Hibernate 官方 ImplicitNamingStrategyJpaCompliantImpl，在 determineBasicColumnName() 里判断“属性是否多语字段”→ 截取前缀 → 拼接“_语言后缀” → 返回新列名。例：实体属性 name.cafMlcen → 映射数据库列 name_en。

③ 一行 YAML 注入 spring.jpa.properties.hibernate.implicit_naming_strategy: com.inspur.caf.CAFImplicitNamingStrategy 启动即生效，零 XML、零注解、零反射工具类。

05/ 实测：30 分钟完成国际化改造

· 旧表：t_product 已有字段 name_zh、name_en

· 新实体：

@Entity
public class Product {
    @Id
    private Long id;
    private String code;
    @Embedded
    private CAFMultiLanguageColumn name;
}

· 旧 DAO 接口直接继承 JpaRepository<Product,Long>，JPQL 写法不变：select p from Product p where p.code = ?1

· 业务层：product.getName().getValue("en") → 返回 name_en 列数据。

· 新增语种？在 CAFMultiLanguageColumn 里加一行枚举 + 数据库加列，实体不动，接口不动，SQL 不动。

06/ 性能白皮书

· 走原生 JDBC 列映射，无反射、无运行时代理。

· 与手工写 5 个字段的 POJO 对比，TPS 下降 < 1%，内存占用持平。

· 支持二级缓存、批量插入、动态查询（CriteriaBuilder），与 Spring Data 全套兼容。

07/ 适用场景

SaaS 多租户、跨境 ERP、全球电商、多语 CMS、政务双语系统……只要 Spring Boot + Spring JPA + Hibernate，复制源码即可落地。

08/ 彩蛋：未来规划

· 2509 资源元数据接入 weblate，自动翻译提升产品翻译速率；

· 2026 Q1 推出动态编译嵌入类型，增加语种不再需要调整嵌入类型代码。

欢迎大家积极留言共建，期待与各位技术大咖的深入交流！

此外，欢迎大家下载我们的inBuilder低代码社区，可免费下载使用，加入我们，开启开发体