JBuilder数组去重问题的分析与解决方案

问题现象

在使用JBuilder 2.13.0版本时，开发者发现当使用json.merge!方法合并包含重复元素的数组时，输出的JSON结果会自动去除重复值。例如：

json.merge!({ test: [1, 1, 2] })

预期输出应为：

{
  "test": [1,1,2]
}

但实际得到的结果却是：

{
  "test": [1,2]
}

问题根源

经过深入分析，这个问题并非直接由JBuilder本身引起，而是源于Ruby的deep_merge方法实现差异。具体表现为：

1. 当调用{}.deep_merge({test: [1, 1]})时，返回结果为{:test=>[1]}，即自动去除了数组中的重复元素
2. 这种行为的根本原因是项目中混用了两种不同的deep_merge实现：
   • active_support/core_ext/hash/deep_merge（正常行为，保留数组原样）
   • danielsdeleo/deep_merge gem（自动去重行为）

技术背景

在Ruby生态中，deep_merge方法用于深度合并哈希结构，但存在多种实现：

1. ActiveSupport实现：

   • 随Rails框架提供
   • 保持数组元素原样，不做任何修改
   • 是大多数Rails开发者预期的行为

2. deep_merge gem实现：

   • 独立的Ruby gem
   • 对数组元素执行去重操作
   • 可能在某些特定场景下被引入项目

解决方案

针对这个问题，有以下几种解决方案：

方案一：强制使用ActiveSupport实现

在项目初始化时（如config/initializers目录下创建文件），添加以下代码：

Hash.prepend(ActiveSupport::DeepMergeable)

这种方法明确指定使用ActiveSupport的深度合并实现，确保数组元素保持原样。

方案二：检查并移除冲突依赖

1. 检查Gemfile.lock文件，确认是否引入了deep_merge gem
2. 如果该gem不是必需依赖，可将其移除
3. 如果必须使用，考虑通过版本锁定或猴子补丁来修正其行为

方案三：自定义合并逻辑

对于需要精确控制合并行为的场景，可以自定义合并方法：

def safe_deep_merge(hash1, hash2)
  # 自定义合并逻辑
end

最佳实践建议

1. 依赖管理：

   • 在Rails项目中，优先使用ActiveSupport提供的扩展方法
   • 谨慎引入功能重叠的第三方gem

2. 版本控制：

   • 明确指定关键依赖的版本
   • 定期检查依赖冲突

3. 测试验证：

   • 对JSON序列化等核心功能编写单元测试
   • 特别关注边缘情况（如包含重复元素的数组）

总结

JBuilder数组去重问题实际上揭示了Ruby项目中一个常见的依赖冲突场景。通过理解不同deep_merge实现的差异，开发者可以更好地控制数据序列化行为。在Rails生态中，坚持使用ActiveSupport提供的标准实现通常是最安全的选择，可以避免这类意外行为。

对于遇到类似问题的开发者，建议首先检查项目中的gem依赖关系，明确各扩展方法的来源，然后选择最适合项目需求的解决方案。