为什么协程不是“线程切换更方便”的创新，而是“结构化并发”？

• a) 每个协程必须属于某个 Scope；如文件必须属于文件夹，

  class UserViewModel : ViewModel {
  fun load {
  viewModelScope.launch {
  repository.loadUser
  }
  }
  }
  
  b) 父子关系：cancel Parent 则所有子任务自动 cancel，无需手动 stop。
  `coroutineScope { launch{ loadUser } launch{ loadOrder } }`
  
  GlobalScope 被官方建议避免：因为它脱离任何父节点和生命周期。`GlobalScope.launch {}`
  没有父节点、生命周期归属、取消关系和异常归属。
  
  `withContext` 与 `launch` 本质区别：
  `withContext{ api.getUser }` - 切换执行上下文，保持同一 Task；`launch{ api.getUser }` - 创建新 Job，即生命周期与异常传播都发生变化。`withContext`: 改变的是执行线程；`launch`: 改变的是任务归属。`
  
  大量项目出现 “Repository 滥用 launch” 的反模式。
  
  
  说到痛点概览，缺乏明确的任务归属与生命周期控制导致内存泄漏和错误处理失效。
  
  
  Cascade cancellation 未生效 → 页面销毁后后台请求仍在跑。
  
  Error propagation 被吞 → UI 层无法正确展示错误信息。
  .
  
  UserExperience 抖动 → UI 状态不一致或闪退。
  .
  
  
  
  
  
  从第二章来看，协程的两层结构
  
  至于第一层。生命周期结构
  
  `Lifecycle-aware Scope 是必不可少的约束，让每个 coroutine 都能被父级管理。例如 ViewModel 有自己的 viewModelScope。`.
  
  至于第二层，取消结构
  
  `coroutineScope{ launch{...} launch{...} }` 自动构造父子关系。cancel Parent 即可 cancel 子 Tasks。.
  
  为什么 GlobalScope 被官方建议避免？
  
  痛点： GlobalScope 无法跟随业务流程自动取消或错误捕获；导致后台服务永远运行或无法优雅退出。
  
  
  
  withContext 与 launch 本质区别****
  
  
  `withContext{…}` – 同一 Task，只改变执行上下文。不改变 Job 或 Cancellation behavior.
  .
  
  `launch{…}` – 新建 Job，产生新的 Cancellation scope 与 Exception handling.
  .
  
  `withContext`: 用来切换工作线程；`launch`: 用来开启新的业务单元/Task.
  .