SwiftData删除模型后插入数据触发EXC_BAD_ACCESS错误排查

可能原因1：上下文保存未完成就执行插入 #

eraseData中删除数据后的保存操作如果是异步执行，或者未等待保存完成就立刻调用插入逻辑，此时SwiftData的上下文可能还处于删除操作的同步过程中，插入时会访问到未完全同步或已释放的内存区域，触发崩溃。

修复方法 #

确保删除后的上下文保存操作完全完成后再执行插入：

func eraseData() async throws {
    // 删除所有Day、Habit实例
    let dayFetch = FetchDescriptor<Day>()
    try context.fetch(dayFetch).forEach { context.delete($0) }
    
    let habitFetch = FetchDescriptor<Habit>()
    try context.fetch(habitFetch).forEach { context.delete($0) }
    
    // 同步保存上下文，确保删除操作彻底完成
    try context.save()
    
    // 执行登出逻辑
}

调用时等待eraseData执行完毕：

try await eraseData()
saveTodOrDay()

可能原因2：跨线程访问ModelContext #

SwiftData的ModelContext并非线程安全，如果eraseData在后台线程执行，而saveTodOrDay在主线程直接复用同一个上下文，并发操作会导致上下文状态混乱，引发内存访问错误。

修复方法 #

• 所有上下文操作统一在同一个线程执行（比如主线程）；
• 后台操作需创建独立的后台上下文：

let container = // 获取你的ModelContainer实例
let backgroundContext = container.backgroundContext
backgroundContext.perform {
    // 执行删除逻辑
    try? backgroundContext.save()
}

插入操作也要对应使用正确的上下文，避免跨线程复用同一实例。

可能原因3：Hashable实现存在内存风险 #

Day类自定义Hashable时，如果hash值计算依赖了SwiftData管理的属性（如自动生成的id），或者在实现中访问了已释放的对象引用，插入新实例时会触发内存访问错误。

修复方法 #

简化Hashable实现，直接基于SwiftData自动生成的id来实现：

@Model
final class Day: Hashable {
    var date: Date
    // 其他业务属性
    
    static func == (lhs: Day, rhs: Day) -> Bool {
        lhs.id == rhs.id
    }
    
    func hash(into hasher: inout Hasher) {
        hasher.combine(id)
    }
}

注：SwiftData的@Model类默认已实现Equatable，自定义Hashable时避免引入额外的内存依赖。

可能原因4：上下文被登出逻辑意外释放 #

登出用户的逻辑可能导致持有ModelContext的对象被销毁，此时再用该上下文执行插入操作，会访问已释放的内存空间。

修复方法 #

• 检查登出逻辑，确保插入操作时使用的ModelContext处于有效状态；
• 登出后如果需要重新初始化数据，应创建新的ModelContext实例，而非复用旧实例。

内容的提问来源于stack exchange，提问作者Mark George