Swift使用FirebaseDecoder解析自定义类时查询结果存在冗余节点的问题

你遇到的嵌套结构不是解析异常，是Firebase Realtime Database的标准查询返回逻辑，同时和不同端SDK的解析默认逻辑有关：

• 你当前查询的目标是列表容器节点（比如/users），容器下的每条业务数据都是通过childByAutoId自动生成的随机主键（示例中的hjhj）作为标识，挂载username、email等业务字段
• 执行条件查询时，快照会天然保留每条匹配数据对应的主键标识，因此会出现外层随机键包裹业务字段的嵌套结构
• Java端SDK的解析逻辑默认会自动遍历快照子节点提取对应业务对象，Swift端的FirebaseDecoder需要显式传入子节点的平铺value才能得到相同效果，这也是你参照Java实现出现结构不匹配的核心原因
• 这个随机键并非无意义冗余，是后续更新、删除对应数据行的必要索引，仅可在解析阶段按需忽略，无法通过查询参数直接移除

方案1：解析阶段手动剥离外层随机键（无需调整现有数据结构，适配90%场景） #

现有代码如果直接把整个容器快照丢给FirebaseDecoder解码，就会因为结构不匹配出现嵌套问题，调整方式为：

1. 先将容器快照的子节点遍历取出，每个子节点的value本身就是你期望的平铺业务字段结构
2. 针对单个匹配结果（比如按唯一邮箱查询用户），取第一个匹配子节点的value走解码流程即可

代码示例：

// 拿到查询返回的原始快照后，先提取匹配的子节点数组
guard let matchSnaps = snapshot.children.allObjects as? [DataSnapshot],
      let firstMatch = matchSnaps.first else {
    // 无匹配数据的处理逻辑
    return
}
// 直接解码单个子节点的平铺value，即可得到正确的自定义类实例
guard let user = try? FirebaseDecoder().decode(
    UserModel.self,
    from: firstMatch.value as Any
) else { return }

如果是多结果列表场景，可遍历所有匹配子节点，收集每个子节点的value后批量解码为模型数组，完全剔除外层随机键。

方案2：调整数据存储结构，从根源消除嵌套 #

如果你的业务场景完全不需要保留自动生成的随机主键，可将原列表存储结构调整为「用全局唯一业务字段作为节点主键」的形式：

• 原结构（会触发嵌套返回）：

  /userList/
    /hjhj: {username: "uiii", email: "test@rom.com"}
  

• 调整后结构（可直接返回平铺字段）：

  /userList/
    /test@rom.com: {username: "uiii", email: "test@rom.com"}
  

调整后，如果你需要查询某个邮箱对应的用户，甚至无需执行排序查询，直接定位到对应主键的节点取值即可，拿到的快照value直接就是平铺的业务字段，无任何嵌套。
注意：该方案要求作为主键的业务字段必须全局唯一，否则会出现同主键数据覆盖的问题。

方案3：服务端过滤字段（高级场景适配） #

如果你的场景需要完全在服务端处理掉嵌套结构，可结合Cloud Functions的实时数据库触发器，对查询返回的结果做结构转换后再同步到客户端，该方案仅适合对性能要求较低、不想调整客户端解析逻辑的场景，不推荐常规业务使用。

内容的提问来源于stack exchange，提问作者it75