NSFetchRequest如何感知当前作用域的NSManagedObjectContext？存储位置求解

你的推测完全正确——Core Data 确实是通过**线程局部存储（Thread-Local Storage）**来让NSFetchRequest在perform()块内自动识别上下文的，而且这个存储容器是框架内部的私有实现，难怪你找不到公开的访问入口。

具体来说，当你调用managedObjectContext.perform { ... }或者performAndWait { ... }时，Core Data 会在代码块执行的线程上，把当前的NSManagedObjectContext实例绑定到一个线程专属的私有存储里。这个绑定操作是在代码块执行前完成的，执行完毕后还会自动清理，避免线程上下文污染。

当你在这个代码块里调用NSFetchRequest.execute()时，方法内部会悄悄去这个线程局部存储里查找当前活跃的上下文：

• 如果能找到匹配的NSManagedObjectContext，就用它来执行查询请求；
• 如果找不到（比如你在perform()块外直接调用execute()，或者上下文没有被正确绑定），就会触发你遇到的「请求未关联上下文」错误。

不止execute()，Core Data 里不少操作都依赖这个机制——比如你直接初始化NSManagedObject而不指定上下文时，它也会自动从线程局部存储里取当前上下文。

至于为什么你找不到这个存储位置？因为这是 Core Data 的私有实现细节，Apple 并没有把它暴露在公开 API 或头文件里。这样做的目的是让框架团队可以自由优化内部逻辑，而不会因为公开了实现细节而被开发者依赖，导致后续版本的兼容性问题。

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