SwiftData中@Query返回模型的属性变更时，onChange(of: results)为何不触发？

我之前也碰到过一模一样的问题，折腾了好一会儿才摸透SwiftData和SwiftUI响应式机制的配合逻辑，结合你给出的代码和测试场景来拆解一下：

核心原因：@Query集合的变更检测逻辑 #

@Query返回的是SwiftData托管的模型对象集合，它的变更通知机制有两个关键特点，刚好对应你的测试结果：

1. 仅关注集合的结构变化：当你向数组中添加/删除元素时，SwiftData能明确检测到集合的“元素组成”发生了变化，所以onChange(of: messages)会正常触发——这也是你前两个场景（增删元素）能生效的原因。
2. 忽略元素内部属性的变化：SwiftData判断@Query集合是否变化的依据是元素的存在性（即是否是同一个SwiftData托管对象），而不是对象内部属性的改动。哪怕你给MessageData自定义了Equatable实现，SwiftData在标记集合变更时，也不会把元素内部属性的变化算进去——毕竟数组里的元素还是那些对象引用，集合本身的“身份”在SwiftData眼里没有变，自然不会触发集合级别的变更通知。

从你整理的触发场景对比表也能验证这一点：

• 元素增删时，onChange(of: messages)✅触发；
• 单个元素etag变化时，无论是onChange(of: messages)还是.task(id: messages)都❌无法触发，本质就是SwiftData没把内部属性变化视为集合的变化。

你的解决方案为什么生效？ #

你测试的onChange(of: messages.map { $0.etag })和.task(id: messages.map { $0.etag })能成功触发，核心是绕开了集合的默认检测逻辑，直接监听属性的变化：
messages.map { $0.etag }会生成一个由所有元素etag组成的新值类型数组，当任意一个元素的etag改动时，这个新数组的内容就会发生变化，SwiftUI通过值类型数组的相等性判断（逐个元素比较）能立刻检测到变化，从而触发回调。

其他可选的优化思路 #

除了你已经验证的方法，还有两种常见的处理方式供你参考：

1. 精准监听多个属性：如果需要同时监听多个内部属性的变化，可以把这些属性组合成一个元组数组，比如：

.onChange(of: messages.map { ($0.etag, $0.text) }, initial: true) { _, _ in
    prepareDisplayMessages(messages: messages)
}

这样只要etag或text任意一个变化，都会触发回调。

2. 监听ModelContext的全局变更（慎用）：如果你的业务逻辑需要响应任意SwiftData模型的变化，可以监听ModelContext的变更通知：

@Environment(\.modelContext) private var modelContext

var body: some View {
    MessagesView(messages: displayMessages)
        .onReceive(modelContext.publisher(for: \.autosaveEnabled)) { _ in
            prepareDisplayMessages(messages: messages)
        }
}

不过这种方式比较宽泛，会在很多无关的场景下触发，不如你用map属性数组的方式精准。

总结 #

SwiftData的@Query集合默认只关心元素的增删，不追踪元素内部属性的变化。如果你需要监听内部属性的改动，最直接且精准的方式就是像你那样，显式监听由目标属性组成的数组，让SwiftUI能准确捕捉到这些细节变化。

内容来源于stack exchange