是的，几乎可以确定崩溃的根源就在FXEditorViewController.loadBadges()里的嵌套闭包（closure #3 in closure #1 in closure #2），下面给你拆解原因和调试方向：

为什么崩溃提示指向AppDelegate？ #

你看到的崩溃指向class AppDelegate: UIResponder, UIApplicationDelegate {这一行，其实是个“假象”——这只是程序崩溃后回溯到主线程入口的终点，而非问题的起点。当未捕获的NSException抛出时，系统会一路回溯到UIApplicationMain函数（你的main方法在AppDelegate.swift第8行调用了它），调试器就会把AppDelegate的类定义行标出来，但真正的错误发生在更早的调用栈里。

崩溃的核心原因 #

崩溃日志里的关键错误信息：

[_NSTaggedDate countByEnumeratingWithState:objects:count]: unrecognized selector sent to instance 0x8000000000000000

这说明某个代码试图把一个_NSTaggedDate（苹果内部标记的Date类型对象）当作可枚举集合（比如Array、Set）来遍历——countByEnumeratingWithState:objects:count是Sequence协议的底层方法，Date对象根本没有实现这个方法，所以抛出了未识别选择器的异常。

为什么锁定loadBadges()的闭包？ #

你提到的Original Exception Backtrace已经给出了明确的线索：

0 exceptionPreprocess
9 Sequence<>.contains(:)
10 closure #3 in closure #1 in closure #2 in FXEditorViewController.loadBadges()
19 UIApplicationMain
20 main
21 start

这个回溯直接显示：异常发生在Sequence<>.contains(_:)方法调用时，而这个调用正是来自FXEditorViewController.loadBadges()里的嵌套闭包。也就是说，在这个闭包内部，你调用了contains(_:)方法，但调用的目标对象不是集合类型，而是一个Date对象。

调试建议 #

• 直接断点定位：在FXEditorViewController.loadBadges()方法内部，尤其是闭包中涉及contains(_:)调用、或者处理Date对象的代码块设置断点，运行App直到崩溃触发，查看此时变量的类型和值。
• 符号断点精准捕获：添加一个符号断点，符号设置为-[NSObject doesNotRecognizeSelector:]，这样当异常触发时，调试器会直接停在错误发生的精确位置，而不是回溯到main函数。
• 检查变量类型：排查闭包中捕获的变量，有没有可能某个原本应该是集合类型（比如Array）的变量，被错误地赋值成了Date对象——比如可选值解包错误、异步回调中变量被意外覆盖等情况。
• 验证contains(_:)的调用目标：确认调用contains(_:)的对象确实是符合Sequence协议的集合（Array、Set等），而不是Date或者其他非集合类型。

内容的提问来源于stack exchange，提问作者lurning too koad