为何withContext代码块会等待挂起函数内启动的协程完成？

问题原因拆解 #

你的代码中，withContext块执行完weirdFunction()并打印Step 1后，没有立即执行后续的Step 2，而是等待10秒才执行，核心原因在于CoroutineScope(coroutineContext).launch的错误使用：

• 作用域与Job的绑定关系：CoroutineScope(coroutineContext)并没有创建独立的协程作用域，而是直接复用了当前挂起函数所在协程的coroutineContext——其中包含了当前withContext协程的Job对象。
• 结构化并发的父子Job规则：调用launch时，新启动的协程会自动成为当前Job的子Job。根据Kotlin协程的结构化并发规则，父协程（这里就是withContext对应的协程）必须等待所有子Job执行完毕后，自身才会进入完成状态。
• 执行流程的阻塞逻辑：weirdFunction()调用后会立即返回（因为launch是非阻塞的），但withContext协程不会立即结束，它会等待那个执行delay(10_000)的子协程完成，才会让代码流程走到Step 2的打印逻辑。

正确实现方案 #

如果你需要在挂起函数内启动不影响调用方作用域的非阻塞协程（即子协程的生命周期不绑定到调用方协程，调用方无需等待它完成），可以采用以下几种方式：

1. 创建独立的协程作用域 #

通过构造新的Job来创建独立作用域，避免复用当前协程的Job，这样新启动的协程就不会成为调用方协程的子Job：

suspend fun weirdFunction() {
    // 用新的Job + 当前调度器创建独立作用域
    CoroutineScope(Job() + coroutineContext[CoroutineDispatcher]!!).launch {
        delay(10_000)
    }
}

这种方式下，weirdFunction()执行后立即返回，withContext块会直接走到Step 1打印，随后withContext结束，Step 2立刻打印，子协程会在后台独立执行10秒。

2. 自定义作用域管理生命周期（推荐） #

在实际项目中，更推荐创建自定义的CoroutineScope并手动管理其生命周期（比如在类销毁时调用cancel()），避免全局作用域的弊端：

// 自定义作用域，比如在类中声明
private val customScope = CoroutineScope(Job() + Dispatchers.Default)

suspend fun weirdFunction() {
    customScope.launch {
        delay(10_000)
    }
}

// 在合适的时机（比如类销毁时）取消作用域
fun onDestroy() {
    customScope.cancel()
}

3. 使用GlobalScope（仅简单场景临时使用） #

GlobalScope是全局协程作用域，其启动的协程不绑定任何局部作用域，但缺点是难以管理生命周期，容易引发内存泄漏：

suspend fun weirdFunction() {
    GlobalScope.launch {
        delay(10_000)
    }
}

第三方库场景的应对 #

如果遇到第三方库的挂起函数存在此类阻塞问题，调试起来确实棘手，可通过以下方式规避：

• 查看库的官方文档，确认其挂起函数是否会启动绑定到调用方的子协程；
• 将库的挂起函数调用放到独立的协程中执行，避免阻塞主业务流程；
• 如果库允许传入自定义作用域，优先传入独立的作用域，隔离生命周期。

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