SwiftData：优化从建模开始
内容提要
SwiftData 处理大数据集时性能不佳，主要因为缺少惰值机制，查询即加载全部属性，导致内存占用高。建议按使用频率拆分模型，将详情字段放入关联对象，列表仅加载轻量数据。临时方案可用 fetchIdentifiers 配合 HistoryObserver，但非最佳。核心是设计时避免宽模型，以提升列表性能。
延伸解读
性能瓶颈的根源：缺少惰值机制
SwiftData 在查询时会将所有属性立即加载到内存，缺乏 Core Data 的惰值机制。实测中，仅获取 3000 条记录就占用约 176 MB 内存，即使只读取标题，正文和附件也会一并加载。这导致列表性能下降，尤其在数据量增大时更为明显。
propertiesToFetch 无效的陷阱
开发者可能尝试使用 FetchDescriptor 的 propertiesToFetch 来只获取部分属性，但在 SwiftData 中该选项并未生效。SQL 调试显示，即使设置了该属性，生成的 SQL 仍会 SELECT 所有列。这可能是 SwiftData 的一个长期 Bug，因此不能依赖此功能优化性能。
模型拆分：按使用频率设计
由于 SwiftData 缺乏惰值机制，模型设计需更严格地按使用频率拆分。将详情字段（如正文、附件）放入关联对象，列表仅加载轻量数据。实测中，拆分后加载时间从 0.30 秒降至 0.029 秒，内存占用从 176 MB 降至不足 1 MB，性能提升显著。
临时方案与权衡
对于已上线的应用，可结合 fetchIdentifiers 和 HistoryObserver 获取动态 ID 列表，但需注意 cell 初始结构变重、行高估算可能引起滚动抖动。此方案仅为权宜之计，并非最佳实践，核心仍应在设计阶段避免宽模型。
Q&A
SwiftData 处理大数据集时性能不佳的主要原因是什么？
SwiftData 缺少惰值机制，查询或 @Query 返回结果时会立即加载所有属性，导致内存占用高和列表卡顿。
为什么 SwiftData 的 propertiesToFetch 没有效果？
即使设置了 propertiesToFetch，SwiftData 仍会加载所有属性，生成的 SQL 也会选择所有列，这可能是框架的一个长期 Bug。
如何通过拆分模型来优化 SwiftData 列表性能？
按使用频率拆分模型，将详情字段（如正文、附件）放入关联对象，列表只加载轻量数据。例如，将 Note 拆分为 Note（标题、日期等）和 NoteBody、NoteAttachment 等关联模型。
SwiftData 和 Core Data 在惰值加载方面有何不同？
Core Data 支持惰值（fault）机制，对象在访问属性前不会加载全部数据；SwiftData 没有公开的惰值 API，查询后所有属性立即加载。
SwiftData 中拆分模型后，cell 中访问关系数据会不会更慢？
在 SSD 上，关系访问是快速的主键读取，不会显著变慢。列表性能瓶颈主要在于一次加载大量宽字段对象，而非滚动时访问少量关系。
对于已上线的 SwiftData 应用，有什么临时性能优化方法？
可以使用 fetchIdentifiers 结合 HistoryObserver 获取 ID 列表，然后在 cell 中按 ID 加载数据。但这不是最佳方案，可能导致行高跳动和滚动抖动。
SwiftData 的设计原则是什么？为什么它不支持惰值加载？
SwiftData 面向 SwiftUI，旨在降低学习门槛，隐藏复杂细节，因此没有提供惰值等高级优化。它更依赖设备性能，而不是让开发者手动管理对象图。
SwiftData 拆分模型时需要注意哪些关系约束？
需要显式定义逆关系，CloudKit 下关系必须可选，对多数组不要在循环中反复 append。
