- 本文章所使用的 OkHttp 源码版本：3.12.10
源码解析
- 老套路，还是从 OkHttp 用法开始入手这块的源码
- 这个方法看起来有点可疑，让我们接着看是不是这个方法
- 看到这里我们基本可以断定这里就是 OkHttp 拦截器整个流程的源码了，接下来让我们看看这里面添加了哪些拦截器
到了这里，我们大致对这几个拦截器有了基本的认识，那么问题来了，为什么要有这么多拦截器？写这些拦截器的主要作用是什么？这些拦截器的执行流程到底是什么样的？
首先 OkHttp 整个流程是由五个关键的拦截器完成的，这五个拦截器的职责明确，从一些拦截器的名称大概就可以猜出来，例如 CacheInterceptor，从这个名字我们基本可以猜出来它是负责处理请求缓存的，一套完整的网络请求流程很复杂，需要执行几万甚至几十万行代码，如果都写在一个类里面可想而知是一件多么恐怖的事情，而拦截器的作用是将这些代码根据职责进行分类。
至于拦截器的执行流程，我们可以看一下这段代码
- 我们可以看到，在添加完一些关键的拦截器之后，最终传入到了一个拦截链中，最后调用了执行的方法。接下来让我们看看这个方法里面做了什么操作
- 接下来让我们重点分析一下这三句源码的作用
- 这里有一个有趣的现象，一个类在方法体中 new 了自己，这个稍微有点难理解，但其实跟递归差不多
- 我们可以看到，拦截链会根据索引获取指定位置的拦截器，并且每 new 一个拦截链对象索引值都会 + 1
最后将拦截链对象传递给拦截器。
等下，你刚刚不是说 proceed 方法会递归？递归在哪里呢？
RealInterceptorChain.proceed() -> Interceptor.intercept() -> RealInterceptorChain.proceed() -> Interceptor.intercept() -> 以此类推
等下，你不是说有五个拦截器，怎么我只看到了两个拦截器在调用？
嗯，然后呢？还有一个呢？去哪里了？
先不要着急，让我们检查一下少了哪个拦截器没调用 proceed 方法
没错，最后一个拦截器没调用 proceed 方法，那到底是为什么呢？
因为这就是拦截器在调拦截器的游戏，假设总共有五个拦截器，第一个拦截器调用了第二个拦截器，第二个拦截器调用了第三个拦截器，第三个拦截器调用了第四个拦截器，第四个拦截器调用了第五个拦截器，那么问题来了，第五个拦截器要调用谁？
没错，游戏结束了，没有再继续往下传递了，因为所有的拦截器都已经遍历完了
Request 对象经过拦截链的层层传递，直到遍历完所有的拦截器，也就意味着本次网络请求完成了，最终返回 Response 对象
至此，拦截器大致的执行流程到这里就结束了，让我们简单总结一下
源码总结
- OkHttp 整个请求流程是由一条拦截链完成，拦截链会用递归的方式来遍历整个拦截器列表，直到最后一个拦截器才停止递归，等所有的拦截器遍历完了网络请求也就结束了，然后由拦截链返回最终的请求结果。
