Sublime Text 中开发 Kotlin Coroutines 的关键是理解结构化并发与 Flow 范式：协程须绑定明确生命周期的 CoroutineScope，Flow 须冷启动、正确封装与生命周期感知收集。
在 Sublime Text 中开发 Kotlin Coroutines 异步程序，关键不是靠 IDE 的智能提示（Sublime 本身不原生支持 Kotlin 语言服务），而是靠你对结构化并发和 Flow 的清晰理解。只要逻辑到位，即使没有高亮、跳转或自动补全，也能写出健壮、可维护的协程代码。
结构化并发：协程的“作用域”必须明确
结构化并发的核心是：协程不能脱离生命周期独立存在。Kotlin 要求每个协程必须在某个 CoroutineScope 中启动，而这个 scope 又绑定到某个上下文（如 ViewModel、Activity、Application 或自定义生命周期）。在 Sublime 中写代码时，你要主动检查三件事：
- 是否每次 launch/async 都显式指定了 scope（比如
viewModelScope.launch或lifecycleScope.launch），而不是裸调用GlobalScope.launch（已废弃且危险） - scope 是否会在宿主销毁时自动取消（例如 ViewModelScope 会随 ViewModel onCleared 自动 cancel）
- 嵌套协程是否用了
supervisorScope或coroutineScope来控制失败传播——比如并行请求中一个失败不该杀死全部，就该用supervisorScope
Flow：冷流 + 收集 = 主动触发 + 生命周期感知
Flow 是冷流，定义时不执行，只有被 collect（或 launchIn）时才激活。在 Sublime 中写 Flow 逻辑，重点看两处：
- 上游是否用了
flow { … }或asFlow()正确封装异步/序列逻辑，避免在 flow 构建块里直接调用 suspend 函数却没挂起（如漏写delay或withContext） - 下游收集是否绑定到有生命周期的 scope（如
repeatOnLifecycle(Lifecycle.State.STARTED) { flow.collect { … } }），防止 Activity 重建后重复收集或内存泄漏 - 是否合理使用中间操作符：用
stateIn替代手动SharedFlow+launchIn；用catch捕获上游异常；用buffer或conflate控制背压
Sublime 下的实用开发习惯
没有 Kotlin 插件支持？那就靠规范和注释补位：
- 在每个协程启动前加简短注释，标明作用域来源和预期生命周期，例如：// viewModelScope: 自动随 VM 销毁
- Flow 定义处标注发射频率和线程意图，例如：// cold flow, emits on IO, collected on Main
- 用 Sublime 的多光标（Ctrl+Click）快速批量修改 scope 名称，或用正则替换统一调整 collect 位置
- 搭配终端运行
kotlinc -script或 Gradle 构建，快速验证协程行为，把 Sublime 当轻量编辑器用，编译和运行交给命令行
基本上就这些。结构化并发不是语法糖，是约束；Flow 不是替代 RxJava 的新玩具，而是为 Kotlin 协程生态设计的数据流范式。在 Sublime 里写它们，反而让你更专注逻辑本质——不复杂，但容易忽略。
