Core Data入门：边哄睡娃边搞定iOS数据持久化

上周三凌晨1点，我一边用脚轻轻摇着婴儿床（娃刚睡着不能停），一边在Xcode里狂敲代码。那天我们App的2.0版本要提审，产品经理下午三点才甩来一句：“用户反馈设置项老是丢，你看看能不能加个本地缓存？”——而我手头还在跑一个临时爬虫脚本，抓取竞品App的UI配置（别问，问就是“技术调研”）。那一刻我真的想把MacBook塞进尿布台。

但没办法，谁让我是那个“既能带娃又能写Swift”的全职妈妈呢？入职新公司两个月，团队氛围挺好，技术栈偏保守（领导说：“能跑就行，别整花活”），所以像Core Data这种Apple亲儿子方案，就成了我们的首选。今天这篇，就把我踩过的坑、熬过的夜、查过的文档，浓缩成一份真实可用的Core Data入门实战指南。顺便，文末还会聊聊为啥这玩意儿跟爬虫、区块链也能扯上关系（别急，真不是硬凑关键词）。

---

为什么是Core Data？而不是UserDefaults或SQLite？

先说结论：简单结构用UserDefaults，复杂关系用Core Data，超大规模考虑Realm或自研方案。

我们App有个“个性化推荐”模块，需要存储用户的历史浏览记录、收藏标签、行为埋点等，字段多、关联强，还有版本迁移需求。一开始我图省事用了UserDefaults，结果某次测试时发现超过5MB后读写卡到飞起——差点被测试小姐姐拉去“喝茶”。

转投Core Data后，性能直接起飞。它不只是个ORM，而是Apple生态里最深度集成的数据持久化框架：

• 自动内存管理（Faulting机制）
• 多线程安全（通过NSManagedObjectContext隔离）
• 原生支持Swift和SwiftUI
• Xcode自带可视化建模工具（.xcdatamodeld文件）

最重要的是——App Store审核友好！不像某些第三方库动不动被质疑隐私问题（说的就是你，某国产数据库SDK）。

---

实战：从建模到CRUD，一步到位

第一步：用Xcode的图形化工具建模

打开你的项目，在File > New > File...里选Core Data Model。这玩意儿比手写Entity定义直观多了，尤其适合我这种半夜脑子不清醒的时候操作。

比如我们要存一个Article实体：

• id: UUID (Attribute Type: UUID)
• title: String
• content: String
• createdAt: Date
• isFavorite: Boolean

注意：主键千万别用Int自增！Apple官方推荐用UUID或URL（参考Core Data Programming Guide）。我之前偷懒用Int，结果在iCloud同步时炸了——两个设备同时插入，ID冲突直接丢数据。

第二步：生成NSManagedObject子类

选中.xcdatamodeld文件 → Editor → Create NSManagedObject Subclass。Xcode会自动生成Swift文件，比如：

// Article+CoreDataClass.swift
@objc(Article)
public class Article: NSManagedObject {
}

// Article+CoreDataProperties.swift
extension Article {
    @nonobjc public class func fetchRequest() -> NSFetchRequest<Article> {
        return NSFetchRequest<Article>(entityName: "Article")
    }

    @NSManaged public var id: UUID?
    @NSManaged public var title: String?
    @NSManaged public var content: String?
    @NSManaged public var createdAt: Date?
    @NSManaged public var isFavorite: Bool
}

吐槽：这自动生成的代码格式丑得我想重写，但为了兼容性还是忍了。

第三步：搞定Core Data Stack（关键！）

这是最容易翻车的地方。很多教程直接给你个单例，但在真实项目里必须考虑多线程！

我现在的做法（参考Apple WWDC 2019最佳实践）：

class CoreDataManager {
    static let shared = CoreDataManager()
    
    lazy var persistentContainer: NSPersistentContainer = {
        let container = NSPersistentContainer(name: "YourModelName")
        container.loadPersistentStores { _, error in
            if let error = error {
                fatalError("Core Data load failed: \(error)")
            }
        }
        return container
    }()
    
    // 主队列上下文，用于UI绑定（SwiftUI专用！）
    var viewContext: NSManagedObjectContext {
        return persistentContainer.viewContext
    }
    
    // 后台上下文，用于网络请求/爬虫数据入库
    func newBackgroundContext() -> NSManagedObjectContext {
        return persistentContainer.newBackgroundContext()
    }
}

重点：

• viewContext 绑定SwiftUI的@FetchRequest，自动刷新UI
• 耗时操作（比如解析爬虫返回的JSON并存库）必须用newBackgroundContext()，否则主线程卡死
• 别忘了在SceneDelegate里传入viewContext

---

真实场景：如何安全地存爬虫数据？

上个月我们搞了个小功能：自动抓取行业资讯站的文章摘要。爬虫用Swift写的（别笑，Alamofire + SwiftSoup真香），每抓到一条就往Core Data里塞。

错误示范（我第一版就这么干的）：

// 在主线程直接操作！
let article = Article(context: CoreDataManager.shared.viewContext)
article.title = crawledTitle
try? CoreDataManager.shared.viewContext.save() // 卡到用户以为App死了

正确姿势：

func saveCrawledArticles(_ articles: [CrawledArticle]) {
    let backgroundContext = CoreDataManager.shared.newBackgroundContext()
    backgroundContext.perform {
        for item in articles {
            let article = Article(context: backgroundContext)
            article.id = UUID()
            article.title = item.title
            article.content = item.summary
            article.createdAt = Date()
        }
        do {
            try backgroundContext.save()
            // 通知主线程刷新UI（比如发个NotificationCenter）
        } catch {
            print("Save crawled data failed: $error)")
        }
    }
}

经验：爬虫数据往往量大且脏，务必做校验（比如title非空），否则后面查询时各种nil崩溃。

---

那么，区块链在哪？

别急，这就来了。

最近团队在研究一个“用户行为不可篡改”的需求——类似区块链的思路：每次操作生成哈希链。虽然最终没上真·区块链（性能扛不住），但我们用Core Data实现了轻量级审计日志。

做法很简单：

1. 每次修改Article时，生成一个AuditLog实体
2. AuditLog包含：操作类型（create/update/delete）、时间戳、前一状态哈希
3. 新状态哈希 = SHA256(旧哈希 + 当前数据)

func logUpdate(for article: Article, in context: NSManagedObjectContext) {
    let log = AuditLog(context: context)
    log.action = "update"
    log.timestamp = Date()
    log.previousHash = article.lastHash
    article.lastHash = generateHash(from: article)
}

这样，即使本地数据被恶意篡改，也能通过哈希链发现异常。本质上，这就是一个微型区块链——只是共识机制换成“用户自己验证”。

---

性能对比：Core Data vs 其他方案

方案	读取1万条耗时	写入1万条耗时	内存峰值	适合场景
UserDefaults	800ms+	1200ms+	高	少量配置
Core Data (正确用法)	120ms	200ms	低	中等复杂度App
SQLite (FMDB)	90ms	180ms	中	需要SQL灵活性
Realm	70ms	150ms	高	超高性能需求

结论：除非你做金融级App，否则Core Data够用又省心。

---

最后：给新手的血泪建议

1. 永远不要在viewContext里做批量操作——我因此导致过一次线上ANR，被运维钉钉轰炸到凌晨三点
2. 迁移模型用轻量级迁移（Lightweight Migration）：只要不删字段，Xcode自动搞定。在persistentContainer初始化时加：

   let description = NSPersistentStoreDescription()
   description.shouldMigrateStoreAutomatically = true
   description.shouldInferMappingModelAutomatically = true
   container.persistentStoreDescriptions = [description]
   

3. SwiftUI里用@FetchRequest：自动监听变化，比手动observe优雅一万倍
4. 测试时清空数据：在setUp()里调用CoreDataManager.shared.destroyAllData()（自己实现个方法遍历所有Entity delete）

---

写完这篇，娃又醒了。但看着App成功通过审核、用户反馈“设置终于不丢了”，那种成就感，大概就是支撑我边换尿布边debug的动力吧。

对了，如果你也在用Core Data，欢迎留言交流——尤其是怎么优雅处理iCloud同步的（我还在踩坑中😭）。

P.S. 下次想看我怎么用Swift写爬虫绕过反爬？或者用Combine重构数据流？点赞过500立刻安排！