如何在可复用自定义框架中实现并正常运行CoreData

核心问题本质是自定义框架场景下，自动生成的CoreData实体类没有正确纳入框架编译范围、访问权限不匹配，加上资源加载路径的适配缺失，导致代码找不到对应的实体类、运行时加载模型失败。

• 调整CoreData模型的代码生成模式
  打开项目中的.xcdatamodeld文件，选中Word实体，在右侧数据检查器中将Codegen选项从默认的Class Definition修改为Manual/None。
  原自动生成模式下的实体类是编译期临时生成的，不会被打包进框架的导出接口，框架内部代码在编译阶段很容易因为类的生成顺序问题找不到对应的类，手动管理生成规则可以从根源避免这类问题。
• 手动生成适配框架权限的Word实体类
  改完Codegen配置后，通过Xcode菜单栏的Editor > Create NSManagedObject Class流程，为Word实体生成对应的托管对象类文件，两个生成的文件（Word+CoreDataClass.swift、Word+CoreDataProperties.swift）必须在右侧文件检查器中勾选你的自定义框架target的成员资格，不能错误关联到测试target或者宿主App的target。
  由于Game类大概率是对外暴露的公共类，生成的实体类和类内属性需要添加public修饰符，保证框架内部和宿主App调用时的访问权限合规：

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

  // Word+CoreDataProperties.swift
  extension Word {
      @nonobjc public class func fetchRequest() -> NSFetchRequest<Word> {
          return NSFetchRequest<Word>(entityName: "Word")
      }
      // 按照实体实际字段补充对应的public修饰属性
      @NSManaged public var wordContent: String?
  }
  

• 修正框架内的持久化容器初始化逻辑
  原代码直接用NSPersistentContainer(name: "Word")初始化的写法，在框架场景下存在路径问题：框架内置的模型文件是打包在框架自己的bundle中，不是宿主App的mainBundle，默认初始化方法会优先从宿主App的主bundle查找模型文件，不仅容易运行时崩溃，也可能间接导致实体类的匹配问题。
  需要在初始化时显式指定加载当前框架bundle下的模型文件：

  lazy var persistentContainer: NSPersistentContainer = {
      guard let modelURL = Bundle(for: Game.self).url(forResource: "Word", withExtension: "momd"),
            let model = NSManagedObjectModel(contentsOf: modelURL) else {
          fatalError("无法加载框架内置的CoreData模型文件")
      }
      let container = NSPersistentContainer(name: "Word", managedObjectModel: model)
      container.loadPersistentStores { storeDescription, error in
          if let error = error as NSError? {
              fatalError("持久化存储加载失败: \(error), \(error.userInfo)")
          }
      }
      return container
  }()
  

• 修复现有代码的隐藏编译问题
  原代码中定义的let context: NSManagedObjectContext?是不可变存储属性，在initCD()方法里尝试给它赋值的逻辑本身就无法编译。可以将context改为惰性加载的强类型属性，避免可选判断和无效赋值：

  lazy var context: NSManagedObjectContext = {
      return persistentContainer.viewContext
  }()
  

• 不要照搬单App场景下的CoreData初始化逻辑：单App场景下所有资源都在mainBundle中，直接用默认初始化方法就能运行，但框架被多个App复用时，资源归属完全不同，不做bundle适配会直接导致运行时崩溃。
• 不要将CoreData相关的实体类、模型文件挂在宿主App的target下：既然数据库需要内置在框架内部实现复用，所有CoreData相关的资源、类都必须归属框架自身的target，避免不同宿主App的代码冲突，也能从根源上解决类找不到的问题。

内容的提问来源于stack exchange，提问作者Dan Donaldson