本文使用OkHttp 3.14.1版本

OkHttp每次发送请求，最终追溯到RealCall#getResponseWithInterceptorChain()方法：

Response getResponseWithInterceptorChain() throws IOException {
    // 拦截器的集合
    // Build a full stack of interceptors.
    List<Interceptor> interceptors = new ArrayList<>();
    interceptors.addAll(client.interceptors());    // 1. 自定义App拦截器
    interceptors.add(new RetryAndFollowUpInterceptor(client));    // 2. 重试和转发拦截器
    interceptors.add(new BridgeInterceptor(client.cookieJar()));    // 3. 桥接用户请求/响应和网络请求/响应
    interceptors.add(new CacheInterceptor(client.internalCache()));    // 4. 缓存拦截器
    interceptors.add(new ConnectInterceptor(client));    // 5. 网络连接拦截器
    if (!forWebSocket) {
        interceptors.addAll(client.networkInterceptors());    // 6. 自定义network拦截器
    }
    interceptors.add(new CallServerInterceptor(forWebSocket));    // 7. 网络请求和响应

    // 创建拦截器链
    Interceptor.Chain chain = new RealInterceptorChain(interceptors, transmitter, null, 0,
        originalRequest, this, client.connectTimeoutMillis(),
        client.readTimeoutMillis(), client.writeTimeoutMillis());

    /**
     * 省略部分代码
     */

    // 交给拦截器链条处理请求
    try {
        Response response = chain.proceed(originalRequest);
        /**
         * 省略部分代码
         */
    } finally {
        /* 省略 */
    }
}

网上找了个图，感谢Piasy Xu：

https://blog.piasy.com/2016/07/11/Understand-OkHttp

OkHttp自带的拦截器

2. RetryAndFollowUpInterceptor

处理重定向（HTTP 3xx）和一部分失败重试（HTTP 401、407、408和503）；

3. BridgeInterceptor

起到桥接作用，将user request转换为network request交给下游（添加一些请求头），再将下游返回的network response转换为user response（保存Cookie、处理压缩）；

4. CacheInterceptor

处理缓存。包括将HTTP response写入缓存，以及可以从缓存读取响应时拦截网络请求（链条后续的Interceptor将不会被调用）；

5. ConnectInterceptor

与目标服务器建立连接（open a connection），然后交给后续Interceptor处理；

7. CallServerInterceptor

最终环节。与服务器进行网络交互。

用户自定义的拦截器

包括1.App拦截器和5.Network拦截器，官方图示：

两者区别，摘自官方文档：

Application interceptors

    Don't need to worry about intermediate responses like redirects and retries.
    Are always invoked once, even if the HTTP response is served from the cache.
    Observe the application's original intent. Unconcerned with OkHttp-injected headers like If-None-Match.
    Permitted to short-circuit and not call Chain.proceed().
    Permitted to retry and make multiple calls to Chain.proceed().

Network Interceptors

    Able to operate on intermediate responses like redirects and retries.
    Not invoked for cached responses that short-circuit the network.
    Observe the data just as it will be transmitted over the network.
    Access to the Connection that carries the request.

翻译过来，加上我自己的理解：

应用拦截器（Application interceptors）

忽略中间状态的响应，比如重定向和失败重试
即使是从缓存获取响应，也总会调用一次
着重于应用本身的企图，不关心If-None-Match这种会被OkHttp内部处理掉的Header
【这条我认为是最重要的设计思路，App拦截器被设计成用户意图的处理者，并不关心网络请求的细节】
可以不调用Chain.proceed()
可以重发网络请求和多次调用Chain.proceed()
【这两条连起来说。没看源码之前感觉云里雾里，看完就明白文档想表达什么意思了。拦截器链条需要每一个拦截器都调用Chain.proceed()方法交给下一个拦截器处理，即从上一个环节交给下一个环节，N个拦截器才能成为拦截器链条。RetryAndFollowUpInterceptor、BridgeInterceptorApp等等都是如此，除了最尾端的CallServerInterceptor（因为没有下一环节了）。App拦截器是拦截器链条的第一环，它的实现取决于用户意图，如果用户不需要发送请求，就可以不调用Chain.proceed()让拦截器链失效（文档中的用词是“短路(short-circuit)”）；如果用户想要多次发送请求，同理也可以多次调用Chain.proceed()达到目的。】

网络拦截器（Network Interceptors）

可以对中间状态的网络响应进行处理
【Network拦截器位于ConnectInterceptor和CallServerInterceptor之间，因此可以对CallServerInterceptor发回来的网络响应做一些操作】
如果是从缓存获取的Response情况，Network拦截器不被调用
【CacheInterceptor在ConnectInterceptor之前就被调用了，如果从缓存获取到响应，CacheInterceptor之后的拦截器都不会被调用，自然也包括了Network拦截器】
将数据视作通过网络传输
【“Observe the data just as it will be transmitted over the network”，这句话我认为更多在表述设计思想，Network拦截器被设计为处理网络请求的场景（这里是狭义的网络请求，即真正需要通过网络获取数据的场景，有别于从缓存获取响应），开发者在实现Network拦截器时应该考虑到这一点。】
能拿到请求使用的Connection对象
【应该是指okhttp3.Connection接口的实现，即RealConnection的实例。链条前一个环节ConnectInterceptor已经创建了网络连接，可供Network拦截器使用了】

参考

拆轮子系列：拆 OkHttp
https://github.com/square/okhttp/blob/master/INTERCEPTORS.md

OkHttp的拦截器（Interceptor）