我了解这两个调用之间记录在案的差异。但是，有谁知道我注意到以下观察到的行为的原因:
如果我有一个 parentContext 和一个临时的 childContext，我使用 childContext 来编辑、插入和删除对象，if use [childContext objectWithID:objectID];要检索存在于父上下文中的已知现有托管对象，它有时会给我一个带有故障的对象，该对象在被触发时失败并生成异常。我理解 objectWithID: 按照设计，无论给定的 objectID 是否存在实际的 managedObject，它总是返回一个处于故障状态的对象。但是，如果该对象实际存在于父上下文中，我希望在访问任何属性时，该对象将始终从父上下文中成功检索(例如，将触发错误)而不会出现任何问题。如果我使用 [childContext existingObjectWithID:objectID];我发现它确实总是成功。
郑重声明，我已经关闭了子上下文的缓存，并且在调用 [childContext resetContext] 之后会发生同样的行为 - 所以它不是与父上下文不一致的旧缓存数据的产物。
在我看来，文档本身似乎不足以解释这种行为。我当然可以把它归结为经验，只是说“我现在知道总是使用 existingObjectWithID:当将对象 ID 传递给我的子编辑上下文时执行 block ”但我感到不安并且想确切地了解这里发生了什么(不是至少这样我可以理解使用一个作为另一个是否有任何性能影响，但也可以理解约束是什么，这样我可以确保没有一些我在我的代码中不必要地实现然后使用的不良做法修复它的错误或低效调用)。
最佳答案
我在我自己的代码中看到了这种行为(堆栈跟踪来自火星，花了很长时间才找到问题的原因)，我的解决方案是相同的(不再使用 objectWithID: 在子上下文中使用 existingObjectWithID:)。
在我的例子中，我会在父上下文中创建一个对象，立即为其获取永久对象 ID，并使用 UIManagedDocument 的 updateChangeCount:UIDocumentChangeDone 请求保存，这将安排在将来的某个时间保存。我认为这一点是讨论的关键。
然后我将执行网络调用以获取与新创建的对象相关的 XML 数据，然后解析该数据并将其导入 Core Data。这发生在后台线程上，我会将对象 ID 传递给线程，该线程使用线程限制的子导入上下文。
在 iOS5 下，我会在工作线程中使用 objectWithID: 将新对象引入导入上下文。工作正常，没有问题。
在 iOS6 下，这开始失败，出现奇怪的堆栈跟踪，唯一的解决方案是移动到 existingObjectWithID:。在测试中，它似乎是进行此更改的可靠解决方案。
和您一样，我试图找到一些明确的陈述来说明为什么会这样，但一直没有成功。但是，我认为我的代码展示的模式和我看到的堆栈跟踪或许可以解释正在发生的事情。我总是看到试图从持久存储中获取数据时发生崩溃。我相信在 iOS5 下，我通过 UIManagedDocument 请求的保存发生在我的子线程有机会运行之前，因此在我调用 objectWithID: 之前新对象被持久化。从我的崩溃日志来看，在 iOS6 下情况并非如此；线程在对象进入持久存储之前运行，因此它还不能被提取到子上下文中。我的假设是 existingObjectWithID: 确保在尝试获取之前执行任何挂起的 SQL I/O，因此当获取发生在我的工作线程中时，持久存储是一致的。我一直无法找到任何明确的证据来支持这一点，但广泛的测试似乎支持这就是正在发生的事情。
关于ios - objectWithID : versus existingObjectWithID: 之间无法解释的行为差异，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13453100/