SwiftUI应用Crashlytics崩溃排查求助：无UICollectionView却触发崩溃

核心背景：SwiftUI List的底层实现 #

iOS 14及以上版本中，SwiftUI的List底层确实基于UICollectionView实现（iOS 13及更早版本用的是UITableView），所以崩溃日志里的UICollectionView异常完全可能来自你使用的List组件，这是正常现象，无需怀疑日志关联性。

具体排查步骤 #

• 优先检查自动滚动逻辑
  崩溃提示“尝试滚动到索引0但分区无数据”，大概率是代码中存在强制滚动到List第一个元素的逻辑（比如用ScrollViewReader的scrollTo(_:)方法，或者页面初始化时的默认滚动行为），但此时List绑定的数据源数组为空。
  解决思路：所有调用scrollTo的地方，必须先判断数据源是否非空，示例代码：

  @Environment(\.scrollViewReader) private var proxy
  @State private var items: [Item] = []
  
  func scrollToTop() {
      guard !items.isEmpty else { return } // 关键判断
      proxy.scrollTo(items[0], anchor: .top)
  }
  

• 排查数据源的异步更新时序
  检查数据源（比如@Published修饰的数组）是否存在异步更新的情况：比如网络请求失败后清空数组，但滚动逻辑已经触发；或者数据还未加载完成就执行了滚动操作。可以在数据源更新的地方添加Crashlytics自定义日志，记录数组的count变化：

  items = newData
  Crashlytics.crashlytics().log("Items updated, count: \(items.count)")
  

• 关于同一用户3秒内连续崩溃
  这基本不是Crashlytics的统计问题，更可能是用户重复触发了同一个触发条件（比如快速刷新页面、重复进入同一视图），每次操作都会执行空数据源下的滚动逻辑，导致连续崩溃。可以查看Crashlytics中该用户的会话详情，获取具体的操作路径和设备信息，缩小排查范围。

• 针对性添加日志而非全局覆盖
  不需要给所有List加日志，重点关注以下场景：

  1. 有自动滚动逻辑的List
  2. 数据源可能被清空的List（比如搜索结果为空、筛选后无数据）
  3. 涉及异步加载数据的List
     在这些场景的关键节点（数据源更新、滚动操作触发）添加日志，结合Crashlytics的用户ID和会话ID，就能快速定位问题视图。

• 排查潜在的UIKit残留或第三方组件
  虽然你说已经移除所有UICollectionView，但仍需检查：

  • 是否存在UIViewRepresentable封装的UIKit组件，底层用到了UICollectionView
  • 是否引入了第三方SwiftUI组件，其内部依赖UICollectionView
  • 有没有遗留的UICollectionViewFlowLayout等相关代码，可能间接触发异常

• 深挖崩溃堆栈细节
  仔细查看Crashlytics的崩溃堆栈，寻找SwiftUI相关的调用栈（比如SwiftUI.ListCoordinator、SwiftUI.CollectionView等类），这些信息可以帮你定位到具体的List视图。如果堆栈中包含你自己的代码方法，那就是直接的排查突破口。

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