OkHttp核心机制深度剖析：拦截器、连接池与缓存策略

聊到Android网络层绕不开OkHttp。这个由Square团队开源的HTTP客户端几乎成了整个Android开发圈的事实标准——Retrofit的网络请求默认交给它执行Glide的图片下载底层也借了它的力市面上绝大多数App的请求背后都有它的影子。这篇文章不打算写入门教程式的使用方法而是从框架设计者的视角把OkHttp的请求执行流程、拦截器机制、连接池复用、缓存策略这些核心模块逐个拆开来讲顺带把我实际项目中踩过的坑也一并交代清楚。适合谁看如果你正在被OkHttp源码面试题折磨或者已经在项目里用了OkHttp但遇到超时、连接失败、内存上涨这类问题只能靠重启应用暂时躲过去那这篇文章应该能帮你把思路彻底捋顺。我会尽量用说人话的方式把每个机制背后的“为什么”讲清楚而不是单纯贴几段源码了事。1. OkHttp到底解决了什么问题1.1 没有OkHttp之前Android网络层有多难受Android早期官方推荐的网络库是HttpURLConnection后来又有Apache HttpClient这俩用起来都算不上顺手。HttpURLConnection的功能极其基础没有连接池的概念每次请求都要重新走一遍TCP三次握手遇到弱网环境简直是灾难。而且它API设计得也很别扭想要自定义超时、加请求头、处理重定向都得写一堆样板代码。Apache HttpClient功能倒是丰富但它实在太重了而且和Android系统版本的兼容性问题一直存在Google后来干脆在Android 6.0里把Apache HttpClient移除了。如果你经历过那个年代一定记得为了在Android项目里用HttpClient而手动添加依赖、还要处理各种类冲突的糟心事。OkHttp就是在这个背景下出现的。它就像是给Android开发者定制的一把瑞士军刀把HTTP协议层面那些琐碎但至关重要的能力都做了完整的封装连接池自动复用TCP连接、透明的GZIP压缩、强大的响应缓存、基于拦截器的灵活扩展。最关键的是它把这些能力藏在了简单直观的API背后日常使用只需要几行代码就能发一个请求完全不用关心底层细节。1.2 OkHttp的核心能力清单我在跟团队新人聊天时经常说理解一个框架最好的方式不是先看它怎么用而是先看它解决了哪些问题。OkHttp的核心能力可以归纳成这样六点第一HTTP/2与连接复用。它自己维护了一个连接池多个请求可以共享同一个底层TCP连接在HTTP/2下还能多路复用大幅降低网络延迟。第二拦截器链设计。这是OkHttp的灵魂所在网络请求从准备到发送、从响应回收到重试处理全部通过拦截器串联开发者也能非常优雅地插入自定义逻辑。第三透明的GZIP压缩。请求体自动压缩、响应体自动解压对调用方完全透明。第四响应缓存。通过标准的HTTP缓存协议它可以帮你把一次请求的响应缓存下来下次同样的请求直接从缓存读取省流量又提速度。第五连接失败自动重试与重定向处理。如果连接失败会尝试备用路由遇到301、302也会自动跟进重定向。第六WebSocket支持。用同一套调用模型支持长连接场景。把这些能力串起来看你会发现OkHttp做的正是“把HTTP协议真正用好”这回事。面试时候被问“为什么Retrofit要选OkHttp做底层”标准答案其实就是这句话因为HTTP协议里那些提升性能的机制OkHttp已经帮你处理得明明白白了。2. 从一次请求开始看OkHttp的执行链路2.1 发一个最简单请求背后有哪些对象在协作不论用OkHttp发什么请求最基本的三个角色是Request、Call和Response。你可以这样理解它们的关系Request描述“我想发什么”Call描述“这次请求的执行过程”Response描述“服务器回给我什么”。下面的代码是最典型的同步请求写法val client OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(15, TimeUnit.SECONDS) .build() val request Request.Builder() .url(https://api.github.com/repos/square/okhttp) .header(Accept, application/json) .build() // 同步请求会阻塞当前线程 client.newCall(request).execute().use { response - if (!response.isSuccessful) throw IOException(Unexpected code $response) println(response.body?.string()) }有些朋友第一次看这段代码时会有个疑问newCall()到底做了什么实际上newCall()返回的是一个RealCall对象它才是真正干活的家伙。RealCall内部持有OkHttpClient、Request以及一个Dispatcher的引用后续所有执行逻辑都是从这里展开的。同步请求用起来简单但有个硬约束不能在主线程使用。Android的主线程一旦被网络耗时操作阻塞轻则界面卡顿重则直接抛NetworkOnMainThreadException崩给你看。所以实际项目里更多用异步方式。2.2 DispatcherOkHttp的线程调度中心异步请求调用的是enqueue()方法传入一个Callback对象请求完成之后回调会在后台线程触发不会堵住UI线程。client.newCall(request).enqueue(object : Callback { override fun onFailure(call: Call, e: IOException) { // 请求失败注意这里还是在子线程 } override fun onResponse(call: Call, response: Response) { // 请求成功但仍然是子线程不能直接操作UI } })你可能会好奇异步请求的“异步”是谁实现的答案是Dispatcher。它是OkHttp自己管理的线程池调度器核心作用有三个维护同步请求队列、维护异步请求队列、控制最大并发数。Dispatcher默认有两组关键参数maxRequests是同一时刻异步请求的最大并发数默认64maxRequestsPerHost是同一Host的最大并发数默认5。这两个参数很有意思它们决定了你的App在大量请求同时发起的场景下系统资源会不会被打满。我见过一些线上问题就是因为有人把maxRequests调得特别大结果瞬间几百个线程同时抢CPU应用卡成PPT这种场景往往不是网络问题而是并发调度失控。Dispatcher内部使用的是ExecutorService线程池但默认的线程池没有核心线程最大线程数是Integer.MAX_VALUE配合SynchronousQueue实现了一种“来一个任务就起一个线程任务结束就回收线程”的策略。如果你对线程池的参数比较熟会意识到这是一种适合大量短时并发任务的配置。想要自定义线程池可以通过OkHttpClient.Builder.dispatcher()传入自己构建的Dispatcher。2.3 请求从发起到响应完整链路是怎样的一次请求真正发出去之前需要经过好几道关卡。我画一张文字版的执行链路图应用层调用 execute/enqueue ↓ 应用拦截器addInterceptor 添加的 ↓ RetryAndFollowUpInterceptor重试与重定向 ↓ BridgeInterceptor桥接请求头/响应体 ↓ CacheInterceptor缓存读写 ↓ ConnectInterceptor建立连接 ↓ CallServerInterceptor真正与服务器交换数据 ↓ 返回 Response 给调用方这个链路中的每一环都是一个拦截器它们在Response真正返回给调用方之前形成了一个“洋葱模型”或者说“流水线”。请求从外往内一层层穿透响应从内往外一层层返回。这就是OkHttp最经典的设计——拦截器链。理解了这条链你对OkHttp的执行机制就有了整体把握接下来逐个拆解这些拦截器思路会更清晰。3. 拦截器链理解OkHttp的设计灵魂3.1 责任链模式把复杂的请求处理拆成一个个独立关卡拦截器链的本质是责任链模式。把“发一次请求”这件麻烦事拆成多个环节每个环节只关注自己的那一小块职责然后像流水线一样依次执行。这样做的好处特别明显新增一个能力不需要改原有的代码只需要往链里插入一个新的拦截器扩展性和可维护性都很好。你可以把拦截器链想象成公司里的审批流程。你提交一个报销单它要依次经过组长、经理、财务的审批。每个人只检查自己负责的那一项审批完之后传给下一个。如果你想加一道“法务审批”不用把之前的流程推倒重来在链上多挂一个节点就行。OkHttp的拦截器链也是同一个道理。在源码层面每个Intercept接口的核心方法就一个interface Interceptor { fun intercept(chain: Interceptor.Chain): Response }chain对象代表连接当前拦截器和下一个拦截器的纽带。当前拦截器处理完自己的逻辑之后调用chain.proceed(request)把请求传给下一个拦截器拿到Response再处理后返回。这样的设计天然支持“请求前做点事、拿到响应后再做点事”的AOP式编程。3.2 内置的五个拦截器分别干了什么先说说RetryAndFollowUpInterceptor。它负责两件事连接失败后的重试以及HTTP重定向的自动跟进。重试不是无脑重试如果请求虽然失败但已经向服务器写入了数据再重试就可能造成重复提交所以这种场景OkHttp是默认不重试的。重定向则是根据响应码和Location头再次发起新请求默认最多跟进20次避免死循环。然后是BridgeInterceptor。它负责把开发者写的Request“翻译”成真正满足HTTP协议规范的请求。举个例子你没有手动设置Content-Length和Host头它会帮你补充你请求的是网页内容它会默认加上Accept-Encoding: gzip响应回来时再自动帮你解压。这个拦截器默默地做了很多“填坑”工作所以你在代码里完全不需要手动处理gzip解压。CacheInterceptor是缓存模块的入口。它会根据请求的缓存策略检查本地有没有可复用的缓存有就直接返回没有才继续往下走。拿到响应之后它还会判断这个响应能否被缓存、缓存多久。这块我后面专门用一章来细说。ConnectInterceptor负责建立TCP连接或者从连接池里捞一条可复用的连接。这里要重要提一点HTTP/1.1下一条连接同一时刻只能处理一个请求所以如果一个Host的并发请求超过连接数队列里就得排队。StreamAllocation这个类就是负责连接分配和复用的关键角色。最底层是CallServerInterceptor。它通过连接将请求头发送到服务器读取响应状态行、响应头、响应体然后封装成Response对象往上返回。这一层已经触及了HTTP协议最底层的报文交互。3.3 自定义拦截器的最佳实践OkHttp允许我们通过两种方式插入自定的拦截器addInterceptor()添加的是应用拦截器addNetworkInterceptor()添加的是网络拦截器。它们的区别很关键应用拦截器位于链的最外层无论缓存命中与否都会执行网络拦截器位于缓存之后、连接之前只有真正发起网络请求时才会执行。实际项目里最常见的自定义拦截器有这么几类统一打印日志的、统一添加鉴权Token的、统一做请求加密的、统一统计耗时的。我分享一个最实用也最简单的日志拦截器写法class LoggingInterceptor : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val request chain.request() val startTime System.nanoTime() // 请求前打印 println(-- Sending request: ${request.method} ${request.url}) val response chain.proceed(request) val duration TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startTime) // 响应后打印 println(-- Received response for ${response.request.url} in ${duration}ms) println(-- Response code: ${response.code}) return response } }拦截器顺序影响特别大这一点我在项目里吃过亏。比如你要做统一的Token刷新逻辑如果把它放在权限拦截器之后可能请求已经被拦截器拦截了Token还没刷新的问题就会出现。另一个常见坑是如果在拦截器里调用了chain.proceed()之后又对响应做了修改比如统一解密响应体一定要记得Response是不可变的需要用response.newBuilder()来构造新响应返回否则直接改动会引发异常。4. 连接池与连接复用OkHttp高性能的底牌4.1 为什么说一次TCP连接的开销远超你想象一个HTTP请求真正传数据的时间往往很短但建连的时间可能比传输本身还长。TCP三次握手需要一到两个RTT如果走HTTPS还要再加上TLS握手的一到两个RTT。RTT就是数据包从客户端到服务器的往返时间按照移动网络平均50到100毫秒来算一次新连接光是握手就得消耗上百毫秒。所以连接复用的意义就是把“每次请求都重新握手”的成本降到最低。第一次请求建立连接后服务器和客户端都维持这条连接后续请求直接复用传输数据就快得多了。OkHttp内置的连接池就是这个思路的工程实现。4.2 OkHttp的连接池是怎么设计出来的连接池的核心类是ConnectionPool内部维护了一个ConcurrentLinkedQueue来存放空闲连接。它有几个重要的默认参数最大空闲连接数maxIdleConnections默认为5空闲连接存活时间keepAliveDuration默认为5分钟。也就是说一个连接空闲下来后最多在池子里待5分钟超过时间就会被清理线程回收避免长时间占着socket资源。我记得这个参数在Android平台上被一些大厂调整过因为不同厂商的网络栈优化策略不同有的会把keepAliveDuration调短一些减少服务器端维护无谓连接的压力。实际开发中如果不是特别了解业务场景不建议乱调默认值在绝大多数场景下表现都很稳定。连接池还有一个专门的清理任务它内部会周期性扫描池里的空闲连接把超过存活时间或者超过最大数量的连接关闭掉。这个清理逻辑不是简单地“每隔X秒扫一次”而是会根据最近一个空闲连接的时间动态计算下一次清理时机尽可能减少无谓的唤醒操作。4.3 路由机制连接池怎么决定复用哪条连接说到连接复用就不得不提Route的概念。一个URL可能解析出多个IP地址OkHttp会按顺序尝试连接这些地址直到某个IP成功建立了连接。这个尝试的过程依赖于RouteSelector。连接复用的一个关键前提是路由必须匹配。如果请求A走了IP1请求B想复用同一条连接那它对应的IP也得是IP1。用生活化的类比来解释连接池就像租车公司的停车场里面停着几辆车但是每辆车只服务指定的几条路线。你要去的目的地正好有对应的车在你才能直接开走否则还得现场调度。这个机制导致了在实际弱网环境中一个非常常见的现象当网络从WiFi切到4G或者域名解析结果发生变化后原本可复用的连接突然失效了OkHttp会重新发起连接。有些经验不足的开发者遇到这种情况会误以为是域名问题实际上这是路由选择更新的正常表现。5. 缓存策略让OkHttp帮你省流量5.1 HTTP缓存协议客户端和服务端的“协商”OkHttp的缓存完全遵循HTTP标准缓存协议不是自己拍脑袋定的规则。这个协议说起来也不复杂核心围绕两个问题响应能不能缓存缓存有效期有多长服务端通过响应头告诉客户端缓存策略最常见的字段是Cache-Control。比如Cache-Control: max-age86400表示这个响应可以被缓存1天在1天内客户端再发同样请求可以直接用缓存。ETag和Last-Modified则是另一种玩法它们不直接说“可以缓存”而是提供一个“验证令牌”客户端带上这个令牌发个条件请求服务端发现内容没变就返回304客户端继续用本地缓存内容变了才返回200和新的响应体。很多开发者只会在Retrofit或OkHttp的配置里加一句cache就以为万事大吉了其实这远远不够。服务端如果不设置任何缓存相关的响应头OkHttp默认是不缓存响应体的。你配置了缓存目录但服务端响应没有给出允许缓存的标识结果还是每次请求都走网络。5.2 OkHttp中如何开启和验证缓存开启OkHttp缓存非常简单只需要在构建客户端时提供一个指定大小的Cache对象val cache Cache( File(context.cacheDir, http_cache), 50L * 1024 * 1024 // 50MB ) val client OkHttpClient.Builder() .cache(cache) .build()这里有两个细节值得注意。第一缓存目录必须是应用可读写的目录context.cacheDir是最常见的选择不要放到externalStorage这种需要权限的地方。第二缓存大小不是越大越好过大的缓存会让磁盘空间吃紧而且OkHttp的缓存索引本身也要占用内存一般控制在10MB到50MB之间比较合适。想要验证缓存是否真的生效可以用日志拦截器打印响应头。当OkHttp命中缓存时返回的Response里会带一个特殊的头字段okhttp-cache值为GET FROM CACHE或者类似标识。如果没有这个头字段说明这次请求实际上走了网络。还有一个更直观的方式用Charles或Replay这类抓包工具看有没有发真实的网络请求。5.3 缓存刷新和禁用的坑我踩过缓存带来的最典型问题就是“数据不新鲜”。比如一个App的首页接口设了很长的max-age用户每次打开App看到的都是旧数据。要强制刷新可以在请求头里加Cache-Control: no-cache它的意思是“不要直接拿缓存先去服务端验证一下”服务端返回304就继续用缓存返回200就更新缓存。还有一类场景是同一个接口需要区分缓存和不定制缓存比如用户信息接口必须实时而配置类接口可以缓存一小时。这个需求可以在OkHttp拦截器里动态判断URL给特定请求追加缓存头。我在实际项目里遇过一个特别诡异的问题某个版本的App内嵌H5页面图片总是显示旧版本。排查下来才发现问题不在前端而在后端返回的HTML和图片资源都没有设置正确的缓存头OkHttp默认不缓存导致每次加载全是全量请求在弱网场景下自然会卡顿。后来和后端同学约定好静态资源统一设置Cache-Control体验立竿见影。6. 协议层面的能力HTTP/2、HTTPS、WebSocket6.1 HTTP/2多路复用一个连接处理无数请求HTTP/1.1的队头阻塞问题相信大家都有耳闻同一个连接上如果前一个请求迟迟没响应后面的请求就得排队等着。HTTP/2通过多路复用解决了这个问题它允许同一个TCP连接上同时交错传输多个请求和响应每个请求被切分成一个个二进制帧用流ID来区分归属。OkHttp从很早就支持了HTTP/2。当客户端和服务端都支持HTTP/2时OkHttp会优先使用HTTP/2协议多个请求共享同一条连接大幅降低连接数量。我在压测时观察过这个效果同样一批请求HTTP/1.1下可能要建立十几个连接切到HTTP/2后只需要两三个连接就能跑完。要查看当前连接用的什么协议可以通过response.protocol字段获取它会返回Protocol.HTTP_2或Protocol.HTTP_1_1。如果发现线上流量都是HTTP/1.1大部分原因是服务端支持不到位或者服务端网关关闭了HTTP/2这种情况下可以考虑在CDN或负载均衡层开启HTTP/2支持。6.2 HTTPS证书校验安全性和开发便利性的权衡默认情况下OkHttp的HTTPS校验是非常严格的它会验证证书链、验证明文、验证域名。这也是它默认为安全起见把很多不合法证书直接拒掉的原因。但开发中经常会遇到自签名证书或内网测试证书导致的握手失败。很多初学者图省事直接写一个信任所有证书的TrustManager把校验关掉。这种做法极其危险等于把应用的大门敞开任何中间人都能拦截你的数据明文传输的内容相当于裸奔。我在代码评审时看到这种写法一般都会要求打回。正确的做法是把你的自签名证书导入到应用的res/raw目录构建自定义的SSLSocketFactory时使用这个证书。这个过程略繁琐但这个复杂性是必须承担的。生产环境的HTTPS配置更应该敬畏证书锁定Certificate Pinning是一个更高级的方案但要注意它有爆炸半径如果服务端证书轮换而App没及时更新锁定指纹所有请求都会失败。6.3 WebSocket长连接用OkHttp实现实时通信极其需要简单写一下因为OkHttp提供了非常便捷的WebSocket支持。普通的WebSocket场景比如IM消息推送、股票行情刷新用OkHttp都很合适。val request Request.Builder() .url(wss://echo.websocket.org) .build() val listener object : WebSocketListener() { override fun onOpen(webSocket: WebSocket, response: Response) { webSocket.send(Hello, WebSocket!) } override fun onMessage(webSocket: WebSocket, text: String) { println(收到消息: $text) } override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) { println(WebSocket 连接失败: ${t.message}) } } val webSocket client.newWebSocket(request, listener) client.dispatcher.executorService.shutdown()这里有个小坑必须提醒上面的webSocket对象如果不保存引用有可能被GC回收导致连接莫名断开。所以实际使用中应该把WebSocket对象保存在一个单例或长生命周期对象里。另外WebSocket的心跳检测需要自己处理OkHttp不会帮你自动发ping如果你只是断线之后重新连接网络层可能会因为长时间没有数据交换而被服务端或中间设备断开。6.4 Retrofit、协程与OkHttp的黄金组合现在真正写Android应用很少有人直接面对OkHttp的Call接口更多是通过Retrofit封装一层。Retrofit用了OkHttp作为底层平台把接口定义变成了可调用的服务方法。协程普及之后配合suspend函数网络请求的写法变得极其优雅interface ApiService { GET(user/info) suspend fun getUserInfo(Query(id) userId: String): UserInfo } class UserRepository(private val api: ApiService) { suspend fun fetchUserInfo(userId: String): UserInfo { return api.getUserInfo(userId) } }Retrofit对OkHttp完全是“组合优于继承”的经典示范你依然可以在构建Retrofit时把自定义的OkHttpClient实例传进去拦截器、缓存、超时这些能力全部继承自OkHttp。在实际项目中我的做法是把OkHttpClient做成一个全局单例统一配置超时、日志、缓存、拦截器不同业务模块共用这一个实例避免每个模块各自创建客户端导致连接池浪费。7. 常见问题与排查技巧实录OkHttp虽然稳定但实际项目里该踩的坑一个都少不了。我把这些年做Android网络层排查时遇到的高频问题整理成一张速查表希望能帮你省点时间常见问题典型现象排查思路解决方案CLEARTEXT通信被禁止请求报错CLEARTEXT communication to xxx not permittedAndroid 9之后默认禁止明文HTTP流量使用HTTPS或按需在networkSecurityConfig里允许特定域名明文连接超时频繁SocketTimeoutException接口偶尔慢看是不是弱网或者服务端响应慢分段设置connectTimeout、readTimeout区分读超时和连接超时域名解析失败UnknownHostException只在一个网络环境出现换网络测试抓日志看DNS解析是否正常给OkHttp配置自定义DNS做本地解析缓存或备用域名HTTPS证书校验失败接口突然全部失败报SSLHandshakeException看是否服务端证书过期或没配完整证书链更新证书客户端做证书锁定前确认轮换机制上传大文件OOM上传视频或大图片时内存暴涨默认RequestBody会把流读入内存使用自定义RequestBody用流式写入避免整个文件进内存缓存不生效设置了cache但还是每次走网络抓包看响应头有没有Cache-Control、ETag让服务端补充缓存响应头确认响应码是可缓存的我挑两个特别值得展开的说一下。第一个是超时问题。很多同学以为设置了readTimeout就一定不会超时其实这里的超时针对的是“两个数据包之间的间隔时间”不是“整个请求的耗时”。如果服务端一直每隔几秒给你发一个包证明自己还活着但整个请求拖了几分钟readTimeout是不会触发的。所以如果需要控制整个请求的最长耗时得自己用call.timeout()来实现。第二个是上传大文件OOM。默认的RequestBody.create()会先把整个内容读取到内存再写入请求体如果你上传一个2GB的文件内存直接爆掉。这时候需要自定义RequestBody自己实现writeTo()方法用文件流边读边写。这是我在一个视频分享类App里实际踩过的坑当时线上崩溃率突然飙升定位到就是上传模块的OOM问题。再分享一个排查工具经验遇到OkHttp的异常一定要先看完整的堆栈再结合抓包工具对比请求链路。Android自带的adb shell抓包能力虽然有限但通过Stetho这类工具也能在开发模式看到网络请求。如果是线上问题建议在日志拦截器里把请求URL、响应码、耗时、异常信息都打印出来排查效率会高非常多。8. 我把OkHttp配置成什么样才敢用于生产环境最后分享一段我个人项目里落地的客户端配置可以直接抄作业。这个配置覆盖了超时、缓存、日志、拦截器、错误上报这些生产必需的环节object NetworkManager { private val client: OkHttpClient by lazy { val cache Cache( File(AppContext.get().cacheDir, http_cache), 30L * 1024 * 1024 ) val loggingInterceptor HttpLoggingInterceptor().apply { level if (BuildConfig.DEBUG) { HttpLoggingInterceptor.Level.BODY } else { HttpLoggingInterceptor.Level.NONE } } OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(20, TimeUnit.SECONDS) .writeTimeout(20, TimeUnit.SECONDS) .cache(cache) .retryOnConnectionFailure(true) .addInterceptor(AuthInterceptor()) // 统一加Token .addInterceptor(loggingInterceptor) // 日志打印 .addInterceptor(ErrorReportInterceptor()) // 异常上报 .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES)) .pingInterval(20, TimeUnit.SECONDS) // WebSocket心跳间隔 .build() } fun getClient(): OkHttpClient client }这里要特别说下pingInterval它不只对WebSocket生效对HTTP/2连接也有保活作用。加上之后可以保持长期连接不被中间设备断开但注意不要在每台机器上都开启有少数服务端不支持ping帧的兼容问题。根据我个人的经验OkHttp已经是Android生态里网络层最成熟可靠的选择真正的问题往往出在使用姿势而不是框架本身。多花点时间理解它的连接池、缓存和拦截器机制比盲目追新工具更有价值。如果你在排查网络问题时始终不得要领不妨先从OkHttp的请求日志开始一层一层剥开看很多时候答案就在那条链路的每一个拦截器里。