三、自定义挂起函数与withContext封装

Kotlin 协程有一条最基本的规则：挂起函数只能被另一个挂起函数或者协程调用。反过来，你自己写的函数，只要里面调了别人的挂起函数，就必须在 fun 前面加 suspend，变成自定义挂起函数。这样它才能被协程调用，也能继续被其他挂起函数调用。

用一个简单例子说明：

// Retrofit 定义的挂起函数
interface ApiService {
    suspend fun getData(): Data    // 别人的挂起函数
}

// 你的函数想调用它 → 必须加 suspend
suspend fun fetchAndCache(): Data {        // 自定义挂起函数
    val data = apiService.getData()        // 调用挂起函数
    cache.save(data)                       // 普通函数调用，没问题
    return data
}

这就是 suspend 的传染性：只要你的函数内部出现了挂起点（调了别人的挂起函数），你的函数也必须声明为 suspend。这个规则一层层往上传播，直到被某个协程构建器（launch、async 等）兜底。

回顾续体与状态机中讲到的：suspend 函数编译后会多出一个 Continuation 参数，返回值变成 Object。这意味着挂起函数的函数签名和普通函数根本不同。

当你写 fetchAndCache() 调用 getData() 时：

• getData() 需要一个 Continuation 参数 —— 这个参数必须由调用者提供
• 如果 fetchAndCache() 是普通函数，它自己没有 Continuation，就没法传给 getData()
• 所以 fetchAndCache() 自己也必须是挂起函数，这样编译器才会给它也注入 Continuation 参数，它才能把续体往下传

假设你有这样一段协程代码，既有网络请求又有数据处理：

CoroutineScope(Dispatchers.Main).launch {
    val data = withContext(Dispatchers.IO) {
        // 网络请求代码
        apiService.getData()
    }
    val processedData = withContext(Dispatchers.Default) {
        // 数据处理代码
        heavyComputation(data)
    }
    updateUI(processedData)
}

代码逐渐变长，你想把数据处理逻辑抽离成独立方法。这时候出现两种选择：

private fun processData(data: Data): Result {
    // 数据处理代码
    return heavyComputation(data)
}

// 调用方负责切线程
val processedData = withContext(Dispatchers.Default) {
    processData(data)
}

private suspend fun processData(data: Data): Result =
    withContext(Dispatchers.Default) {
        // 数据处理代码
        heavyComputation(data)
    }

// 调用方只需一行
val processedData = processData(data)

一般情况下，选择 B（挂起函数封装）更优。因为 withContext 本身就是为在协程中执行特定任务而选配合适调度器的，把线程切换逻辑和业务代码封装在一起，调用方更简洁、更安全。

但也存在选择 A 更合适的场景：

选择 B 之后，你可能会有一个顾虑：

这个顾虑非常合理，但协程框架已经为这种情况做了针对性优化。

具体场景：

// 外层协程已经在 Default 调度器上
CoroutineScope(Dispatchers.Default).launch {
    // 当前线程已经是 Default 线程池中的某个线程
    val result = processData(data)  // 内部又包了 withContext(Dispatchers.Default)
}

private suspend fun processData(data: Data): Result =
    withContext(Dispatchers.Default) {
        heavyComputation(data)  // 还切吗？
    }

答案是：不会切。

当你在协程中调用 withContext 切换上下文时，协程框架会检查：新的调度器和当前调度器是不是同一个？判断标准是它们的 ContinuationInterceptor（续体拦截器）是否相同。

如果 ContinuationInterceptor 没有改变，协程就不会切线程，而是直接在当前线程继续执行。这个检查发生在 withContext 的底层实现中：

所以：

• 从 Dispatchers.Default 切到 Dispatchers.Default → 不切线程，直接执行
• 从 Dispatchers.IO 切到 Dispatchers.IO → 不切线程，直接执行
• 从 Dispatchers.Main 切到 Dispatchers.IO → 真正切换线程

如果你的函数是纯计算函数——不涉及挂起、不依赖特定线程——那么可以不封装 withContext，保持普通函数形态：

// 纯计算：不涉及任何协程 API，不需要 suspend
private fun heavyComputation(data: Data): Result {
    // 纯粹的数据处理，跑在哪个线程都行
    return Result(data.items.map { transform(it) })
}

// 调用方根据场景决定要不要切线程
// 场景1：在主线程调用 → 必须切
val result1 = withContext(Dispatchers.Default) { heavyComputation(data) }

// 场景2：已经在 Default 线程 → 不需要切
val result2 = heavyComputation(data)

这种情况下，选择 A（普通函数）反而更灵活——调用方可以按需决定切不切线程。

回到更大的视角：协程因为其语法特性，可以百分百保证耗时操作在正确的线程执行。这是它作为系统设计层面的核心优势。

为什么能保证？三个机制叠加：

• 续体与状态机 —— suspend 函数的编译秘密：理解 CPS 变换和 Continuation 的底层机制
• suspend 与挂起函数：从 Retrofit 到 withContext：suspend 在 Retrofit 中的实际应用，withContext 的命名解析与底层原理
• 四种协程调度器深度解析：Main、Default、IO、Unconfined 的底层实现与 ContinuationInterceptor