如何为@ObservedObject修饰的CoreData实体制作可编辑副本，是否需要这么做？

两个需要先明确的事实：

• CoreData生成的Contact实体是基于NSManagedObject的引用类型类，直接变量赋值只是传递对象指针，根本不会产生独立副本，你遇到的副本失效问题是这类场景的普遍现象，不是代码逻辑本身的问题。
• 关于“未保存的修改不会影响其他页面”的认知存在偏差：CoreData的托管上下文是实时推送实体属性变更通知的，不管你有没有调用save写入磁盘，只要修改了context中托管实体的属性值，所有监听该实体的视图（包括@FetchRequest驱动的联系人列表页）都会立刻收到通知刷新UI。未保存的修改只是不会被写入磁盘持久化，并非完全隔离在当前页面。

这个问题没有绝对答案，完全取决于你的交互设计需求：

• 如果你的编辑页没有“取消/放弃修改”按钮，用户所有输入完成后直接点保存提交，不需要中途退出丢弃编辑内容：直接绑定@ObservedObject修饰的原始Contact实体完全够用。这种场景下利用CoreData的上下文机制就可以实现目标，不需要额外维护副本。
• 如果你的编辑页支持“取消操作”，需要做到“编辑过程中的临时输入完全隐藏，不影响列表页的显示，直到用户主动点击保存才同步变更”：必须使用隔离的编辑副本。直接修改原始实体会带来两个无法回避的问题：
  • 你在输入框里每敲一个字，列表页对应的联系人名称就会跟着实时变化，体验割裂
  • 如果用户中途退出页面，需要手动调用viewContext.rollback()回滚所有未保存的变更，一旦逻辑疏漏，会残留半编辑状态的脏数据，甚至触发其他监听该实体的视图出现异常刷新。

手动拷贝NSManagedObject来做副本是性价比极低的方案，SwiftUI场景下的通用最佳实践是用纯Swift值类型结构体作为编辑草稿，完全不需要依赖托管对象的拷贝逻辑：

1. 定义和Contact实体字段对应的纯值类型草稿模型，所有字段都用基础值类型，关联关系只存对应的对象ID，不直接持有托管对象的引用：

   struct ContactDraft {
       var firstName: String
       var lastName: String
       var birthDate: Date
       var picture: Data?
       var relatedLevelID: NSManagedObjectID?
   }
   

2. 修正初始化的逻辑bug：你目前的代码存在典型的SwiftUI State初始化误区——你在State实例创建完成之后，才给栈上的局部tempContact变量赋值，这些赋值根本不会影响State存储的实际值，最终TextField绑定的永远是空的草稿实例。正确的初始化流程是：先从原始Contact实体提取所有字段值，构造好初始草稿对象，再传给@State的初始值：

   struct ContactProfile: View {
       @Environment(\.managedObjectContext) private var viewContext
       @ObservedObject var contact: Contact
       @State private var draft: ContactDraft
   
       init(contact: Contact) {
           _contact = ObservedObject(initialValue: contact)
           // 先构造完整的初始草稿，再传入State初始化
           let initialDraft = ContactDraft(
               firstName: contact.firstName ?? "",
               lastName: contact.lastName ?? "",
               birthDate: contact.birthDate ?? Date(),
               picture: contact.picture,
               relatedLevelID: contact.level?.objectID
           )
           _draft = State(initialValue: initialDraft)
       }
   }
   

3. 所有表单输入组件的绑定直接操作draft的字段即可。因为draft是纯值类型，所有修改只会存在于当前视图的State存储中，既不会碰到底层的原始Contact实体，也不会触发任何外部视图的刷新，完全实现了编辑内容的隔离。
4. 当用户点击保存按钮时，再把draft中的所有字段值一次性写回原始Contact实体，最后调用viewContext.save()完成持久化：

   private func commitEdits() {
       contact.firstName = draft.firstName
       contact.lastName = draft.lastName
       contact.birthDate = draft.birthDate
       contact.picture = draft.picture
       // 根据存储的关联ID查询对应的Level对象完成关联
       if let levelID = draft.relatedLevelID,
          let level = try? viewContext.existingObject(with: levelID) as? Level {
           contact.level = level
       }
       // 统一保存上下文
       do {
           try viewContext.save()
       } catch {
           // 对应错误处理逻辑
       }
   }
   

为什么不推荐手动拷贝NSManagedObject做独立副本？
如果你用NSManagedObject(context:)创建同实体的临时拷贝，这个对象会自动加入当前托管上下文，立刻被@FetchRequest监听到，导致列表页莫名其妙多出一个重复的临时联系人。如果要创建脱离上下文的纯对象副本，需要手动遍历实体的所有属性、关联关系逐字段复制，工作量大且容易遗漏逻辑，远不如定义一个轻量值类型结构体高效。

• 把原始的Contact引用直接赋值给@State包裹的临时变量：本质还是同一个引用对象，修改@State中的属性就是修改原始实体，完全起不到隔离作用，也是你最初遇到的核心问题。
• 在视图的init中给局部临时变量赋值后再传给State：只要赋值操作发生在State初始化之后，修改的就是栈上的局部变量，根本不会影响State存储的实际值，会出现视图输入框永远为空的bug。

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