求助：排查@main处触发的Thread 1: Fatal error: Index out of range错误

别慌，这种错误不在直接的数组操作代码行出现太常见了——很多时候数组越界是在异步回调、UI更新闭包、或者被其他代码间接调用时发生的，错误栈只是最终指向了程序入口@main。下面是几个实用的调试方法，帮你精准找到问题根源：

1. 用Objective-C异常断点锁定触发点 #

Xcode自带的这个断点能帮你跳过@main的表层错误，直接定位到实际抛错的代码：

• 打开Xcode的Debug菜单，选择Debug Workflow > Breakpoints > Create Symbolic Breakpoint
• 在Symbol栏输入objc_exception_throw，不用改其他设置，直接点击Done
• 重新运行程序，这次会直接停在触发数组越界的代码行，而不是停在@main

2. 添加Swift运行时错误断点 #

专门针对Swift的运行时错误（包括数组越界）设置断点：

• 打开Breakpoint Navigator（快捷键Cmd+8），点击左下角的+号，选择Swift Error Breakpoint
• 保持默认设置即可，下次运行时，只要出现数组越界这类Swift运行时错误，程序会立刻停在出错的位置

3. 排查间接访问数组的潜在场景 #

如果断点没直接命中，就得梳理那些可能悄悄操作数组的地方：

• TableView/CollectionView数据源：比如cellForRowAt里用indexPath.row访问数组，但数组长度和numberOfRowsInSection返回的数量不一致（比如数组已经删了元素，但数据源方法没同步更新）
• 异步回调：网络请求、定时器完成后更新UI时访问数组，这时候数组可能已经被修改，原索引对应的元素已经不存在
• 多线程操作：多个线程同时读写数组，导致数组状态混乱，这种情况建议统一在主线程处理数组的修改和访问
• KVO或属性观察者：监听数组变化的代码里，有没有错误地使用了固定索引值

4. 临时加日志辅助排查 #

如果断点不好用，可以在所有修改或访问数组的地方加日志：

// 修改数组后打印当前长度
print("数组更新后长度: \(array.count)")
// 访问数组索引前先校验并打印
print("准备访问索引\(targetIndex)，当前数组长度: \(array.count)")

运行程序后，看崩溃前最后一条日志，就能知道哪个索引超出了当时的数组长度

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