使用带suspend Lambda的Kotlin协程：此实现是否符合最佳实践？

这种实现整体是合理且适配Kotlin协程场景的实践，但存在可优化的细节，具体分析如下：

核心优势 #

• 适配协程生态：在处理异步IO类操作（比如示例中的saveUserToken本地存储）时，允许在回调Lambda中直接调用挂起函数，无需额外的上下文切换或封装代码，逻辑更简洁自然。
• 链式调用可读性：构建器模式的链式写法保持了代码的流畅性，相比传统when表达式的分支处理，业务逻辑的链路更直观，降低了阅读成本。
• 扩展性强：返回自身的设计支持后续追加更多链式操作，比如在onSuccess后继续处理数据或添加其他回调，灵活性较高。

需要注意的问题 #

1. Failure泛型限制：当前Failure<Nothing>的泛型定义会导致它只能对应APIResponse<Nothing>，但业务中通常需要返回APIResponse<具体类型>，会出现类型不兼容问题。建议修改为data class Failure<T>(val error: Exception) : APIResponse<T>，让Failure可以适配任意T类型的响应。
2. 回调异常风险：如果onSuccess或onFailure的Lambda中抛出异常，会直接向上传播，可能影响整个协程流程。如果需要统一处理回调内的异常，建议在方法实现中用try-catch包裹block调用。
3. 职责耦合：将挂起回调逻辑直接写在APIResponse接口内，让这个原本只负责结果封装的类承担了业务处理的额外职责。如果后续需要支持非协程场景的回调，就得重载方法，增加维护复杂度。

优化建议 #

可以把onSuccess和onFailure抽离为扩展函数，让APIResponse专注于结果封装，职责更单一：

sealed interface APIResponse<T>  {
    data class Success<T>(val data: T) : APIResponse<T>
    data class Failure<T>(val error: Exception) : APIResponse<T>
}

suspend fun <T> APIResponse<T>.onSuccess(block: suspend (data: T) -> Unit): APIResponse<T> {
    if (this is APIResponse.Success) {
        block(data)
    }
    return this
}

suspend fun <T> APIResponse<T>.onFailure(block: suspend (error: Exception) -> Unit): APIResponse<T> {
    try {
        if (this is APIResponse.Failure) {
            block(error)
        }
    } catch (e: Exception) {
        // 统一处理回调内抛出的异常
        e.printStackTrace()
    }
    return this
}

这个改动既保留了原来的链式调用体验，又让APIResponse的职责更清晰，同时还能统一处理回调中的异常。

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