Ktor 全栈之路 (1)：深度解析 Pipeline 架构与拦截器实战

前言

作为一名 资深Android开发，我们习惯了 OkHttp 的 Interceptor 链。当你开始接触 Ktor Server 时，你会发现一个更强大的概念 —— Pipeline（管道）。

理解 Pipeline 是掌握 Ktor 的第一步。它决定了请求（Request）如何一步步穿过层层关卡，最终变成响应（Response）返回给 App。今天我们来拆解这个“万物皆管道”的架构。

---

一、 核心心智：Pipeline 到底是什么？

在 Ktor 中，几乎所有的操作都发生在一个名为 ApplicationCallPipeline 的管道中。这个管道被划分为几个关键的 Phases（阶段）：

1. Setup：配置环境。
2. Monitoring：监控请求（日志记录开始）。
3. Plugins：各种功能插件介入。
4. Call：执行具体的路由（Routing）逻辑。
5. Fallback：如果没处理，最后的兜底。

---

二、 拦截器的威力：编写你的自定义中间件

作为资深开发，你肯定不满足于只写 get("/")。我们需要全局的控制能力。

实战场景：全局 API 耗时统计

val TimingPlugin = createApplicationPlugin(name = "TimingPlugin") {
    onCall { call ->
        val startTime = System.currentTimeMillis()
        call.attributes.put(AttributeKey<Long>("startTime"), startTime)
    }
    onCallRespond { call ->
        val startTime = call.attributes[AttributeKey<Long>("startTime")]
        val duration = System.currentTimeMillis() - startTime
        println("Request ${call.request.uri} took ${duration}ms")
    }
}

---

三、 Ktor 插件 vs OkHttp 拦截器

• OkHttp Interceptor：主要是线性的，侧重于请求头的修改和重试。
• Ktor Pipeline：是多维的。你可以通过 intercept 在任何阶段插入逻辑。它支持协程挂起，这意味着你的拦截器可以去读数据库或调外部 API，而不会阻塞主流程。

---

四、 架构建议

1. 逻辑解耦：将通用的校验（如 API 版本检查、签名验证）封装成独立的 Plugin，而不是写在每个 Route 里。
2. 异常捕获插件：使用 install(StatusPages) 统一处理异常，将后端的错误堆栈转换为 App 友好的 JSON 格式。
3. 上下文持有：学会利用 call.attributes。这是在不同拦截器之间传递临时数据的唯一正规方式，比全局变量安全得多。

---

结语

Pipeline 是 Ktor 的骨架。掌握了它，你就拥有了掌控全局流量的能力。

下一篇，我们将进入后端开发的硬核地带 —— 协程驱动的高并发：Ktor 如何处理万级连接？