用途：指导 iOS 应用在使用 SwiftData 或 CoreData 做数据持久化时的框架选型、迁移设计与性能优化，重点规避生产环境崩溃。
主要能力：
- 框架选择：新应用且仅支持 iOS 17+、模型简单、需要 iCloud 同步时可考虑 SwiftData；需支持 iOS 16 及更早、使用 NSCompoundPredicate 等复杂查询、UIKit + NSFetchedResultsController、已有 CoreData 代码库或抽象实体/继承时可考虑 CoreData（资料称截至 2025 年 CoreData 性能仍更快）。
- 迁移陷阱：未版本化且已开启 iCloud 同步的架构首次迁移会崩溃，需先用仅含版本化包装、不改 schema 的版本过渡；给含重复数据的字段加 @Attribute(.unique) 前须先做去重迁移；开启 iCloud 后 SwiftData 会阻止破坏轻量迁移兼容性的改动（重命名属性、修改关系删除规则、删除必填属性），只能做增量式变更；大迁移在后台线程初始化 ModelContainer，避免启动白屏。
- 性能模式：为列表/分页设置 fetchBatchSize；BLOB 小于 100KB 可内联，100KB–1MB 用独立实体加关系，超过 1MB 存文件系统并保存路径；关系默认返回 fault，仅预取确定会用到的关系；CoreData 表视图用 NSFetchedResultsController。
- 限制：资料称 iOS 18 时 SwiftData 尚不支持 NSCompoundPredicate、NSFetchedResultsController、抽象实体、子上下文和模型子类化，性能较慢，可用多查询、SwiftUI 的 @Query、协议等变通。
使用方式：按资料给出的迁移检查清单执行——从第一天起定义版本化 schema；复杂变更编写迁移阶段；用 1000 条以上生产数据备份测试；验证后台迁移与 iCloud 同步；新属性设默认值或可选；确认唯一约束只施加在干净数据上。
适用场景：新应用持久化架构设计、既有 CoreData 项目维护、迁移报错排查、抓取性能优化。限制：具体 API 行为随系统版本变化，资料以 iOS 17/18 为参考，未提供价格、安装命令与官方支持信息。