Kotlin协程多数据库查询代码优化及使用疑问

问题a：runBlocking vs coroutineScope的正确选择 #

先明确两者的核心差异和适用场景：

• runBlocking 是阻塞式的桥接工具，它会卡住当前线程，直到内部所有协程执行完毕。它的设计场景是非协程环境调用协程代码（比如main函数入口、普通Java方法里需要触发协程并等待结果）。如果你的代码已经运行在协程上下文里（比如Android的ViewModel用viewModelScope、后端服务的协程作用域），用runBlocking就完全错误——它会阻塞协程所在的线程，违背协程非阻塞的初衷。
• coroutineScope 是挂起函数，它不会阻塞线程，只会挂起当前协程，等待内部所有子协程完成后再恢复。它的作用是在协程内部划分作用域，统一管理子协程的生命周期（比如一个子协程失败，所有子协程都会被取消）。如果你的代码本身就在协程里，这才是正确的选择。

判断标准很简单：当前代码不在协程环境，用runBlocking；已经在协程里，换成coroutineScope。

问题b：runBlocking的返回值与缩小作用域后的结果获取 #

1. 从runBlocking返回完全可行：runBlocking的lambda表达式的返回值就是它自身的返回值，因为它会阻塞到内部所有逻辑完成，所以直接返回合并后的实体是合法的。示例：

fun getMergedEntity(): MergedEntity {
    return runBlocking {
        val data1 = async { db.table1.get() }.await()
        val data2 = async { db.table2.get() }.await()
        val data3 = async { db.table3.get() }.await()
        MergedEntity(data1, data2, data3)
    }
}

这段代码会阻塞当前线程，直到三个异步数据库调用完成并合并成实体后返回。

2. 缩小runBlocking作用域的正确姿势：把核心协程逻辑封装到挂起函数里，只在最外层需要桥接阻塞世界的地方用runBlocking调用它。示例：

// 封装协程逻辑的挂起函数，内部用coroutineScope管理子协程
suspend fun fetchAndMergeData(): MergedEntity {
    return coroutineScope {
        val data1Deferred = async { db.table1.get() }
        val data2Deferred = async { db.table2.get() }
        val data3Deferred = async { db.table3.get() }
        MergedEntity(data1Deferred.await(), data2Deferred.await(), data3Deferred.await())
    }
}

// 非协程环境调用时，用runBlocking做桥接
fun getMergedEntity(): MergedEntity {
    return runBlocking { fetchAndMergeData() }
}

这样runBlocking的作用域仅负责启动协程并等待结果，核心异步逻辑都在挂起函数中，既符合协程最佳实践，代码也更清晰。如果调用方本身就在协程环境（比如Android的ViewModel），连外层的runBlocking都可以去掉，直接调用fetchAndMergeData()即可。

额外补充：如果数据库操作是阻塞式的（而非挂起函数），要把它们放到Dispatchers.IO调度器执行，避免阻塞主线程，比如：

async(Dispatchers.IO) { db.table1.getBlocking() }

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