修改CoreData属性类型报NSCocoaErrorDomain 134140如何解决

你碰到的NSCocoaErrorDomain 134140是CoreData迁移错误，本质原因是直接修改属性类型属于不兼容的模型变更：旧持久化存储里street_no存的是字符串值，和你改完之后的Int64类型不匹配，默认的轻量级迁移无法自动完成跨类型的值转换，所以加载存储时直接崩溃。改回String类型后模型和旧存储匹配，自然就正常运行了。

下面是不同场景下的正规处理方式，比你现在用的16步临时流程要简单可靠：

开发调试阶段（无需保留旧测试数据） #

这是效率最高的方案，不需要做任何迁移配置：

• 直接把street_no的类型修改为目标的Int64
• 删除模拟器/真机上已经安装的旧版App，彻底清除本地旧的持久化存储文件
• 重新编译运行即可，不需要反复删除生成的NSManagedObject子类、清理项目缓存，Xcode会自动生成对应新类型的托管对象代码。

正式发版场景（需要保留用户本地旧数据） #

这种场景需要做版本化数据迁移，正规步骤如下：

1. 创建新版本数据模型
   • 选中项目中的.xcdatamodeld文件，点击Xcode菜单栏 Editor > Add Model Version，基于当前的旧模型创建一个新版本（比如命名为Invoice_Gen_v2）
   • 在Xcode右侧的文件检查器中，将新创建的v2模型设置为Current Model Version，也就是App当前会使用的模型版本
2. 修改新版本模型配置
   • 切换到v2版本的模型编辑器，直接把street_no的类型修改为Int64
3. 配置迁移规则
   两种可选实现，优先选第一种，复杂度最低：
   • 轻量级迁移+自定义值转换：
     首先在初始化NSPersistentContainer时打开自动迁移开关，代码如下：

     lazy var persistentContainer: NSPersistentContainer = {
         let container = NSPersistentContainer(name: "Invoice_Gen")
         guard let storeDesc = container.persistentStoreDescriptions.first else {
             fatalError("No persistent store description found")
         }
         // 开启自动持久化存储迁移
         storeDesc.setOption(true as NSNumber, forKey: NSMigratePersistentStoresAutomaticallyOption)
         // 开启自动映射模型推断
         storeDesc.setOption(true as NSNumber, forKey: NSInferMappingModelAutomaticallyOption)
         
         container.loadPersistentStores(completionHandler: { (_, error) in
             if let error = error as NSError? {
                 fatalError("Unresolved error \(error), \(error.userInfo)")
             }
         })
         return container
     }()
     

     由于String转Int64属于类型不兼容变更，自动推断无法处理值转换，你需要新建一个继承自NSEntityMigrationPolicy的子类，重写属性值转换逻辑，将旧存储中字符串类型的street_no转为Int64类型后赋值给新模型的对应属性，再把这个迁移策略关联到对应实体的映射配置上即可。
   • 自定义映射模型：
     如果本次涉及的模型变更较多，可以直接新建Mapping Model文件，选择源模型为旧版本、目标模型为刚才创建的v2版本，在映射模型中手动配置street_no的转换规则：将旧属性的字符串值调用int64Value转换后赋值给新模型的同名字段即可，不需要创建临时属性绕路。
4. 重新生成对应实体的NSManagedObject子类，编译运行即可。App启动时CoreData会自动按照配置完成迁移，将本地旧数据按规则转换为新模型格式，不会出现崩溃。

补充说明 #

你之前用的新建临时属性、多次重跑的方案，本质是把一次不兼容的类型变更拆成了三次轻量级迁移可以识别的兼容变更（新增Int64类型临时属性、删除旧String属性、重命名临时属性为原名称），所以可以正常运行，但流程冗余且容易因为漏步骤出问题，正式发版不建议使用。

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