UIKit Target-Action选择器是否始终在主线程调用？CoreData崩溃排查

首先直接给结论：UITextField通过addTarget:绑定的selector方法，并不一定100%在主线程执行——这就是你遇到CoreData fetch崩溃的核心原因。

先明确CoreData的红线规则 #

CoreData的NSManagedObjectContext（尤其是默认的主上下文）是线程绑定的：你在哪个线程创建的上下文，就只能在哪个线程上执行读写操作（包括fetchRequest）。如果在非主线程操作主上下文，必然会触发崩溃，这和你看到的调用栈完全吻合——崩溃发生在Thread 0，而主线程是Thread 1（从Thread 1的调用栈里的UIEventFetcher可以判断这是负责UI事件循环的主线程）。

为什么UITextField的selector会跑在后台线程？ #

正常情况下，UIKit的所有用户交互事件（比如文本输入触发的UIControlEventEditingChanged）都是在主线程分发的，但有几个例外场景会导致selector跑到后台：

• 你的UITextField被添加到了一个在后台线程创建的UIView层级里（虽然Apple反复强调所有UI操作必须在主线程，但如果不小心这么做了，事件分发就可能跟着跑到后台线程）
• 有没有手动通过sendAction:to:forEvent:方法，在后台线程触发了这个selector？
• 某些第三方UI库或者自定义的事件分发逻辑，可能修改了事件的线程归属

解决办法 #

不管是什么原因导致selector跑在后台，最稳妥的修复方式是强制把CoreData操作切回主线程，用DispatchQueue.main.async包裹你的fetch代码：

@objc func textFieldTriggeredAction(_ textField: UITextField) {
    DispatchQueue.main.async {
        // 在这里执行你的CoreData fetchRequest
        let fetchRequest: NSFetchRequest<YourEntity> = YourEntity.fetchRequest()
        // 添加查询条件等逻辑...
        do {
            let results = try self.mainManagedContext.fetch(fetchRequest)
            // 处理查询结果、更新UI等操作
        } catch {
            print("Fetch失败: \(error.localizedDescription)")
        }
    }
}

另外，建议你检查下UITextField所在的整个UI视图层级，确保所有UI的创建、更新操作都在主线程完成——这能从根源上避免这类跨线程问题。如果你的项目用了CoreData多上下文架构，也可以考虑用专门的后台上下文执行fetch，再把结果同步回主线程，但对于简单场景，直接切主线程是最省心的方案。

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