到目前为止，我一直使用"main moc"作为主线程，初始化如下:
[[NSManagedObjectContext alloc] init];
，然后我有NSOperation子类与他们自己的moc，从web服务导入数据，我合并在"主"moc保存观察NSManagedObjectContextDidSaveNotification但是现在我需要添加用户可以稍后提交(或不提交)的"临时"对象的能力。所以看起来子上下文非常合适，为了使用子上下文，我将"main moc"的初始化更改为
[[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
问题是:如果与子上下文策略一起使用，我当前的结构与NSOperation子类有自己的moc(在自己的线程中初始化而没有类型)是否有问题?我不这么认为，但我觉得把这些策略混在一起没什么好处。
请注意，我想维护NSOperation子类，我不想使用子上下文也导入我的数据，因为它会影响性能，参见http://floriankugler.com/blog/2013/4/29/concurrent-core-data-stack-performance-shootout
此外，当我创建一个新的子线程的主线程(即类型NSMainQueueConcurrencyType)，我可以创建它的类型NSMainQueueConcurrencyType的子，继续工作与我的对象在主线程像往常一样?还是我被迫使用NSPrivateQueueConcurrencyType，并使用performBlock:对我的对象上的每个操作?我之所以问，是因为从文档中不清楚是否在同一线程(在这种情况下是主线程)上使用2个moc可能是一个问题。
:最后，我在生产中实现并使用了这个解决方案，到目前为止还没有出现问题。我唯一需要做的是避免合并我的NSManagedObjectContextDidSaveNotification通知时，moc有一个parentContext(我们不想合并moc与父上下文，因为他们自己管理合并，但显然通知也触发了save在这种moc)
是的，你可以有多个主线列上下文mocs，正是因为你说的原因-你创建一个临时的编辑上下文来编辑数据，然后根据用户的操作保存或丢弃。
至于混合和匹配与您的操作队列上下文-这应该不是一个问题。如果你合并回父上下文，那么任何子上下文都会在下一次取回数据。
实际上，这是在使用多个线程时显示的。这里，我写了一篇关于这个的文章。其中提到的从moc是专门为操作而设计的，每个操作都在它自己的从moc上。