SwiftData中@Query与@Relationship在视图展示子对象的选型对比

我们的业务场景是实现类似文件夹的无限树形结构（包含文件夹与文件节点），支持节点的添加、删除、编辑和移动操作，下面对比SwiftData中两种获取子节点的方式，分析各自的优缺点。

通用Node模型代码 #

@Model
class Node {
    let id = UUID()
    var parent: Node?
    @Relationship(deleteRule: .cascade) var children: [Node]
    var name: String { "node: \(id)".prefix(5).description }

    init(children: [Node]) {
        self.children = children
    }
}

方式一：使用@Query获取子节点 #

实现代码 #

struct NodeViewUsingQuery: View {
    @Environment(NavigationPathWrapper.self) var navigation
    let node: Node

    // 使用@Query查询子节点
    @Query var childNodes: [Node]
    init(node: Node) {
        self.node = node
        self._childNodes = Query(filter: #Predicate { $0.parent?.id == node.id })
    }

    var body: some View {
        VStack {
            Text("Child Nodes:")
            ForEach(childNodes, id: \.id) { child in
                Text(child.name)
                    .onTapGesture {
                        navigation.path.append(child)
                    }
            }
        }
        .navigationTitle(node.name)
    }
}

优缺点 #

优点

• 自动更新：@Query会自动监听数据变化，子节点增删改时视图自动刷新，无需手动同步数据
• 灵活过滤：可在查询时添加额外条件（比如区分文件夹/文件节点），适配复杂业务需求
• 内存优化：仅加载当前需要的子节点，适合层级极深、子节点数量庞大的场景，减少不必要的内存占用

缺点

• 初始化繁琐：需在View初始化器中手动构造Query并传递过滤条件，代码量相对较多
• 性能开销：每次查询都需和数据库交互，节点数量极大时频繁查询会带来一定性能损耗

方式二：直接使用@Relationship引用子节点 #

实现代码 #

struct NodeViewUsingRelationship: View {
    @Environment(NavigationPathWrapper.self) var navigation
    let node: Node

    var body: some View {
        VStack {
            Text("Child Nodes:")
            ForEach(node.children, id: \.id) { child in
                Text(child.name)
                    .onTapGesture {
                        navigation.path.append(child)
                    }
            }
        }
        .navigationTitle(node.name)
    }
}

优缺点 #

优点

• 代码简洁：直接通过node.children访问子节点，无需额外查询逻辑，代码直观易懂
• 访问高效：子节点作为Node对象的关联属性，直接从内存获取，无需数据库查询，性能更优
• 关系维护便捷：SwiftData自动维护父子节点关联，移动节点（修改parent属性）时，关联的children数组会自动更新

缺点

• 内存占用高：加载父节点时会一次性加载所有关联子节点，层级深、子节点多的场景下易造成内存压力
• 过滤不便：需在内存中对children数组二次过滤才能区分不同类型节点，无法利用数据库查询优化
• 更新依赖父对象：子节点变化触发视图刷新的前提是父Node对象被标记为变化，部分场景下需手动触发刷新

总结建议 #

• 若业务场景节点数量大、层级深，或需要动态过滤不同类型节点，优先选择@Query方式，能更好控制内存、适配复杂查询需求
• 若树形结构节点数量少、层级浅，或更看重代码简洁性和访问性能，直接使用@Relationship更合适

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