Core Data 入门：一个双非自学者的踩坑实录
去年双11那会儿，我还在远程实习，老板丢给我一个“简单”的需求：做个本地任务管理器，支持离线记录、分类筛选、还能同步到后端。听起来人畜无害，对吧？但当我打开 Xcode 新建项目时，才发现——我连数据存在哪儿都没想清楚。
作为一个在 Vim 里写 Swift 的倔强仔（别问我为啥不用 Xcode 自带编辑器，问就是肌肉记忆），我对图形化工具总有点本能抗拒。以前做小 demo 要么用 UserDefaults 存点字符串，要么直接写 JSON 到 Documents 目录。可这次需求明显复杂多了：任务要有关联标签、有创建时间、能排序、还能批量操作。产品经理还暗示说，“以后可能要加 AI Agent 自动归类任务”……我当场就懵了。
没办法，硬着头皮啃文档。Apple 官方力推的 Core Data，成了我唯一的选择。
为啥选 Core Data？真不是跟风
说实话，一开始我是抗拒的。网上一堆“Core Data 很重”“学不动”“不如直接用 SQLite”的声音。但我仔细一想：
- App Store 审核偏好原生方案：用第三方数据库（比如 Realm）虽然方便，但审核时偶尔会卡你“私有 API”问题（别问我怎么知道的，上个项目就被毙过一次）。
- SwiftUI 深度集成：
@FetchRequest这个属性包装器，简直是为列表页量身定制的，自动监听变化、刷新 UI，省掉多少胶水代码。 - 内存优化自带：Core Data 的 faulting 机制能按需加载对象，不像我之前手写 JSON 解析，一加载几百条任务直接 OOM。
最关键的是——我们团队的后端大哥说了：“前端先做好本地存储，同步逻辑我来对接。” 好家伙，这锅甩得干净利落。行吧，那就干。
实战第一步：建模别瞎搞
我第一次建 .xcdatamodeld 文件时，直接把 Task 实体拖进去，加了 title、createdAt、isCompleted 几个字段，然后高高兴兴写代码。结果一运行，崩溃：
CoreData: error: Failed to call designated initializer on NSManagedObject class
查了半天才知道——如果你用了自定义子类，必须调用 init(context:)，而不是默认的 init()。这是 Core Data 的一个反直觉设计：它要求你通过上下文（NSManagedObjectContext）来创建对象，而不是直接 new。
后来我改用 Xcode 自动生成 NSManagedObject 子类（Editor → Create NSManagedObject Subclass），才躲过这个坑。建议新手都这么干，别自己手写，容易翻车。
实体关系设计：别把简单问题复杂化
任务和标签是一对多关系。我一开始想搞成“任务属于多个标签”，于是建了个中间表。结果发现——Core Data 的 To-Many 关系根本不需要中间实体！
直接在 Task 实体里加一个 tags 属性，类型选 “To Many”，目标设为 Tag 实体。反过来，Tag 实体里加 tasks，也是 To Many。Xcode 自动帮你维护双向关系，连 inverse 都给你配好了（记得检查下！inverse 设错会导致保存失败）。
// 自动生成的 Task+CoreDataProperties.swift
@NSManaged public var title: String?
@NSManaged public var isCompleted: Bool
@NSManaged public var tags: Set<Tag> // 注意是 Set，不是 Array！
这里有个细节：Core Data 的 To-Many 默认是无序的 Set。如果你需要有序（比如按添加顺序），得手动改成 NSSet 并启用 ordered 关系（在模型编辑器里勾选）。不过性能会差一点，慎用。
CRUD 操作：别被模板代码劝退
增删改查是基本功，但 Core Data 的写法和其他 ORM 差不多：
// 插入
let task = Task(context: viewContext)
task.title = "写 Core Data 博客"
task.isCompleted = false
// 查询（配合 SwiftUI 的 @FetchRequest）
@FetchRequest(
entity: Task.entity(),
sortDescriptors: [NSSortDescriptor(keyPath: \Task.createdAt, ascending: false)],
predicate: NSPredicate(format: "isCompleted == %@", false)
) var incompleteTasks: FetchedResults<Task>
// 更新
task.isCompleted = true
// 删除
viewContext.delete(task)
// 别忘了保存！
do {
try viewContext.save()
} catch {
print("保存失败：$error)")
}
看起来挺清爽？但实际开发中，我遇到两个大坑：
多线程访问崩溃：Core Data 的 context 不是线程安全的！我在后台队列解析后端返回的 JSON，直接往主 context 插数据，结果随机 crash。解决办法是：每个线程用自己的 context，并通过 parent-child 或 NSPersistentContainer 的 backgroundContext 来协调。
保存失败静默忽略：
try? viewContext.save()这种写法太危险了！有一次因为数据约束冲突（比如重复主键），保存失败但没报错，用户以为操作成功了，结果数据丢了。现在我一律用do-catch，并在 catch 里上报 Sentry。
和后端对接：别让本地变成孤岛
我们的 App 要支持离线使用，所以本地数据必须能和后端同步。这里我和后端约定了几个规则：
- 每条本地任务生成一个 UUID 作为临时 ID
- 后端返回真实 ID 后，本地更新并标记“已同步”
- 冲突处理策略：后端覆盖本地（简单粗暴但有效）
为了不阻塞 UI，我把同步逻辑放在 OperationQueue 里跑。每次启动 App 或网络恢复时，触发 syncManager：
func syncPendingTasks() {
let bgContext = persistentContainer.newBackgroundContext()
bgContext.perform {
let pendingTasks = // 查找 isSynced == false 的任务
for task in pendingTasks {
// 调用后端 API
if apiClient.createTask(task.toDTO()) {
task.isSynced = true
task.remoteID = response.id
}
}
do {
try bgContext.save()
} catch {
// 上报错误
}
}
}
这里要注意：backgroundContext 的 perform 是异步的，别在主线程等它返回！
AI Agent？别想太多，先把基础打牢
说到 AI，其实我们目前只是用 Core Data 存了用户行为日志（比如“用户经常在晚上9点创建‘学习’类任务”），准备未来喂给推荐模型。但现阶段，AI Agent 还没上线。产品经理画的大饼而已。
不过 Core Data 在这里意外地好用：它的批量更新（NSBatchUpdateRequest）和批量删除（NSBatchDeleteRequest）能高效处理大量日志，不会卡住主线程。比如清理30天前的日志：
let request = NSBatchDeleteRequest(fetchRequest:
Event.fetchRequest(predicate: NSPredicate(format: "timestamp < %@", cutoffDate))
)
do {
try viewContext.execute(request)
} catch {
// handle
}
比一条条 delete 快多了。
性能调优：别让 Core Data 背锅
很多人吐槽 Core Data 慢，其实是用错了。分享几个实战经验：
| 场景 | 错误做法 | 正确做法 |
|---|---|---|
| 加载大量列表 | 一次性 fetch 所有属性 | 用 propertiesToFetch 只取需要的字段 |
| 滚动卡顿 | 在 cell 里访问关系属性（如 task.tags） | 预加载或用 fetched property |
| 内存暴涨 | 长时间持有 fetched results | 用 NSFetchedResultsController 分页 |
特别提一下 fetched property：它类似 SQL 的子查询，可以在不加载完整对象的情况下获取聚合数据。比如“每个标签下的未完成任务数”：
<!-- 在 Tag 实体里定义 fetched property -->
<property name="incompleteTaskCount"
fetchedPropertyDefinition="Task WHERE tags CONTAINS $FETCH_SOURCE AND isCompleted == NO" />
这样在列表里显示计数时，不会把所有任务都拉进内存。
App Store 上架：别栽在隐私政策上
去年 Apple 开始严查数据收集。我们因为存了用户任务内容（虽然是本地），被要求提供隐私说明。还好 Core Data 数据默认存在沙盒里，不属于“跟踪用户”，只要在 App Privacy 中声明“Data Not Linked to You”就行。
但如果你把 Core Data 的 sqlite 文件上传到服务器（比如做备份），那就属于“收集数据”了，必须写清楚用途。我们运营同学为此改了三次隐私协议，差点错过上架 deadline……
总结：Core Data 没那么可怕
作为一个双非学校靠 B 站和 Ray Wenderlich 自学 iOS 的学生，我曾经觉得 Core Data 是座大山。但真正用下来发现：只要避开几个经典陷阱，它其实是个稳如老狗的本地存储方案。
特别是现在 SwiftUI + Core Data 的组合，写起来行云流水。上周五晚上加班改 bug 时，看着 @FetchRequest 自动刷新列表，我甚至有点感动——终于不用手动 diff 数组了！
如果你也在做 iOS 应用，又需要结构化本地存储，别犹豫，试试 Core Data。它可能不是最炫酷的，但绝对是 Apple 生态里最“省心”的选择。
最后送大家一句我工位贴的便签（手写拍下来放 Vim 旁边）：
“别怕 Core Data，怕的是不用。”
搞定收工，我去喝杯冰美式压压惊。
评论 0