ISLAND：从一次 iOS 启动崩溃理解 KMP 协程异常边界（island-kmp-sugarlite-crash）
跨平台代码不等于相同运行时
Kotlin Multiplatform 可以让应用共享业务逻辑，但共享代码运行时仍处于不同平台环境。相同的 Kotlin 代码在 Android 和 iOS 上，可能沿着不同的异常传播路径处理错误。开发者若只在一个平台验证正常流程，可能错过另一个平台的进程级故障。
ISLAND 文章记录的现象很直接：轻糖 iOS 版本在冷启动后数秒内稳定出现 SIGABRT，而 Android 对应版本没有相同表现。崩溃堆栈中出现 propagateExceptionFinalResort。作者据此继续检查共享层的 ViewModel 和协程订阅，并将注意力从 Swift 页面代码转向异常如何从 Flow 收集过程向协程根部传播。
Flow 订阅中的异常传播
文章描述的共享 ViewModel 会启动多个协程，分别订阅日数据、周数据和单位等状态。某些订阅内部组合了多个数据流，再将结果更新到界面状态。只要其中一个上游操作抛出异常，例如数据读取或转换失败，异常就可能沿着 collect 调用链向外传播。
这类异步流程容易让问题远离最初的调用位置。开发者在 ViewModel 初始化代码中看到的是启动订阅，但真正失败的操作可能发生在稍后的数据库访问、网络请求或结果映射中。若异常没有在适当的边界被处理，启动协程本身返回并不表示后续任务已经安全完成。
文章特别对照了两端运行时对根部未处理异常的处置。作者指出，其案例中 Android 侧错误会进入 Java 未捕获异常处理路径，而 Kotlin/Native 侧的根协程异常最终触发进程中止。该结论来自作者所记录的具体技术栈和事故现场；其他项目仍需结合使用的 ViewModel 库、协程上下文和依赖版本单独验证。
从崩溃符号还原调用链
当问题表现为冷启动后固定时间崩溃时，堆栈符号可以帮助建立排查方向。文章中的 propagateExceptionFinalResort 并非业务函数名，而是 Kotlin/Native 协程运行时相关符号。作者将它与 SIGABRT、启动阶段的数据加载和 Android/iOS 表现差异结合起来，推断异常到达了没有处理者的协程根部。
定位这种故障时，可以从可复现时序入手：记录启动后哪个 Flow 开始收集，异常是否发生在上游，调用链最终进入了哪个 Job，以及平台运行时如何报告该异常。与其只检查最后一帧界面代码，不如沿着“启动订阅—读取数据—变换结果—更新状态”的过程追踪异常边界。可读的错误日志和带有上下文的堆栈，也有助于避免把运行时差异误判成一般的空指针或数组错误。
订阅级边界与兜底处理
文章讨论的修复思路包括为订阅过程建立异常兜底。关键不在于把所有错误统一吞掉，而在于明确每条异步任务失败时如何被观察、呈现或恢复。一个数据流订阅可以在合适的位置捕获预期的失败，将错误转换为界面状态或重试提示；对于无法恢复的异常，则需要留下足够的诊断信息并交由应用的错误处理策略决定。
在共享层设计中，异常处理需要与业务语义相匹配。例如，网络暂时不可用和本地数据结构不符合预期，可能需要不同处理方式。若统一捕获后仅返回空列表，系统虽然避免了进程退出，却可能掩盖关键错误。对每条 Flow 标明失败可能、决定用户界面如何表达、并在日志中保留必要上下文，通常比设置一个无差别的全局忽略器更容易维护。
为什么要审视 CoroutineExceptionHandler
文章指出，相关 ViewModel 的 viewModelScope 没有安装 CoroutineExceptionHandler。这个观察使异常传播路径变得具体：当子协程中的错误没有在局部被处理，并一路到达根部时，平台可能进入各自的未处理异常路径。开发者需要确认当前 scope 是否提供了预期的处理器，以及处理器适用的协程类型和异常边界。
不过，处理器不能替代局部错误建模。对于 Flow 中可预期的失败，在数据流或业务调用层处理通常更清楚，因为那里掌握请求、数据源和恢复策略的上下文。CoroutineExceptionHandler 更像是最后的观测与兜底机制，适合避免未知错误完全无迹可寻；它并不能自动恢复一个已经处于不一致状态的业务操作。
共享层设计中的平台检查
KMP 项目将更多逻辑放入 shared 模块后，Android 与 iOS 虽共享部分实现，生命周期、主线程调度、错误报告和依赖封装仍可能不同。迁移清单中除了接口和数据模型，还应包括协程 scope 的来源、生命周期取消方式、未处理异常行为以及错误如何传递到各平台界面。
测试也应覆盖运行时差异。开发者可以在模拟失败的条件下分别启动两端应用，观察异常是否被捕获、用户界面是否显示合理状态、日志是否包含诊断线索，以及任务是否按预期取消。对于冷启动数据流，测试应尽量覆盖订阅启动、上游失败和错误恢复，而不只验证成功返回的数据。
从事故复盘形成工程规则
这篇文章把一次稳定复现的 iOS 启动崩溃拆成了现象、堆栈、共享层订阅和平台异常处理几个部分。它提醒读者，跨平台共享逻辑并不会消除平台行为差异，尤其是协程根部的未处理异常。把 Flow 的失败路径、scope 配置和运行时报告方式写入团队约定，可以减少迁移后才发现问题的机会。
ISLAND 还持续记录轻糖的 KMP 渐进迁移，包括数据层下沉、ViewModel 处理和 iOS 侧衔接等主题。读者可以结合这些连续文章理解共享层逐步扩展时的设计取舍。对遇到类似崩溃的开发者而言，站内复盘提供了一条从 SIGABRT 特征追踪到协程异常边界的分析路线；具体修复仍应以自身依赖与运行环境的验证结果为准。