CoroutineScope、coroutineScope与协程扩展函数的差异及适用场景咨询

问题背景 #

我正在学习Kotlin协程，跟随JetBrains的《协程与通道入门》实践教程学习。在结构化并发章节中提到：

可以通过coroutineScope函数在不启动新协程的情况下创建新作用域。若在无外部作用域访问权限的suspend函数内以结构化方式启动新协程，可创建一个自动成为该suspend函数所属外部作用域子作用域的新协程作用域。

假设在一个CoroutineScope内调用loadUsers函数，以下三种实现的运行结果一致：

实现一 #

import kotlinx.coroutines.coroutineScope

suspend fun loadUsers(): List<User> {
    coroutineScope {
        //...
    }
}

实现二 #

suspend fun loadUsers(): List<User> {
    CoroutineScope(Dispatchers.Default).run  {
        //...
    }
}

实现三 #

suspend fun CoroutineScope.loadUsers(): List<User> {
    //...
}

注：函数体内会启动多个协程，完整代码已做简化。

我有两个问题想请教：

• 这三种实现之间有什么差异？
• 是否存在必须使用coroutineScope（小写C）且无法替代的场景？

我已查阅过相关技术问题，但因三种实现效果一致仍有困惑。

一、三种实现的核心差异 #

1. 结构化并发合规性 #

• 实现一（coroutineScope）：完全符合结构化并发规则。自动绑定外部调用者的协程作用域作为子作用域，内部协程受外部作用域追踪——外部取消时内部协程自动取消，内部未捕获异常会传播至外部作用域，导致整个作用域失败。
• 实现二（CoroutineScope(Dispatchers.Default).run）：违反结构化并发。手动创建的CoroutineScope与外部作用域无绑定关系，属于"游离"作用域。外部取消时内部协程不会自动终止，易引发资源泄漏；内部异常仅终止新作用域，不会影响外部调用者的协程。
• 实现三（CoroutineScope扩展函数）：符合结构化并发。函数依托外部作用域启动协程，内部协程均为外部作用域的子协程，受外部生命周期管理。

2. 调度器继承逻辑 #

• 实现一：完全继承外部调用者的调度器，coroutineScope不会改变调度上下文，内部协程默认沿用外部调度环境。
• 实现二：强制使用Dispatchers.Default作为调度器，完全脱离外部调度上下文。
• 实现三：继承外部CoroutineScope的调度器，与调用者的调度环境保持一致。

3. 异常传播行为 #

• 实现一：内部协程的未捕获异常直接向上传播至外部作用域，会终止外部协程。
• 实现二：内部异常仅限制在手动创建的CoroutineScope内，不会自动传递给外部调用者（除非手动处理并传递）。
• 实现三：内部协程异常会传播至外部CoroutineScope，遵循结构化并发的异常传播规则。

4. 生命周期绑定关系 #

• 实现一：内部协程生命周期与外部调用者的协程完全绑定，外部取消时内部立刻终止。
• 实现二：内部协程生命周期独立于外部调用者，外部取消后可能继续运行，造成资源浪费或逻辑错误。
• 实现三：内部协程生命周期绑定到外部CoroutineScope，外部作用域取消时内部协程自动终止。

二、必须使用coroutineScope的场景 #

1. 普通suspend函数内的结构化并发实现 #

当编写非CoroutineScope扩展的普通suspend函数，且需要在函数内部启动协程并保证其生命周期与调用者绑定时，必须使用coroutineScope。普通suspend函数无自带协程作用域，手动创建CoroutineScope会违反结构化并发，而coroutineScope可自动创建绑定外部作用域的子作用域。

2. 等待所有内部协程完成后返回结果的逻辑 #

coroutineScope会挂起当前协程，直到作用域内所有子协程执行完成。如果业务需要等待批量并发任务全部完成后再合并结果（比如多源数据加载后汇总），coroutineScope是最优选择——手动创建CoroutineScope需额外调用joinAll等方法，且无法保证结构化并发；扩展函数方式虽能等待，但依赖外部已有CoroutineScope，普通suspend函数无法直接使用。

3. 确保异常正确传播至调用者 #

当需要内部协程的异常直接触发外部调用者的异常处理逻辑时，必须使用coroutineScope。手动创建CoroutineScope会将异常限制在新作用域内，无法自动传递给外部；而coroutineScope会向上传播异常，符合结构化并发的失败传播规则。

4. 避免不必要的调度器切换 #

如果函数无需改变调度上下文，希望继承调用者的调度器，coroutineScope是最佳选择。手动创建CoroutineScope会强制指定调度器，引发不必要的线程切换；扩展函数方式虽继承调度器，但只能在已有CoroutineScope的环境下调用，普通suspend函数的调用场景更灵活。

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