如何防止 OkHttp 自动覆盖 Content-Type 请求头-java教程-PHP中文网

如何防止 OkHttp 自动覆盖 Content-Type 请求头

OkHttp 的 BridgeInterceptor 会在请求发出前自动根据 RequestBody 的 contentType 覆盖手动设置的 Content-Type 请求头，导致自定义 header 失效；解决方法是使用网络拦截器（network interceptor）或确保 RequestBody 不声明 content type。

okhttp 的 bridgeinterceptor 会在请求发出前自动根据 requestbody 的 contenttype 覆盖手动设置的 `content-type` 请求头，导致自定义 header 失效；解决方法是使用网络拦截器（network interceptor）或确保 requestbody 不声明 content type。

在使用 OkHttp + Retrofit 构建 HTTP 请求时，你可能会遇到一个看似“神秘”的现象：明明在应用拦截器（application interceptor）中通过 addHeader("Content-Type", ...) 显式设置了 Content-Type，但在实际发出的请求中该 header 却被移除或覆盖——而其他自定义 header（如 Content-Type2）却完好无损。这并非 Bug，而是 OkHttp 内部设计的预期行为。

根本原因：BridgeInterceptor 的自动协商机制

OkHttp 在请求链中内置了一个关键拦截器 —— BridgeInterceptor（源码见 okhttp3.internal.http.BridgeInterceptor.kt）。它的职责之一是：

✅ 自动为请求添加标准协议头（如 Host, Connection, Accept-Encoding 等）
✅ 根据 RequestBody.contentType() 的返回值，覆盖（overwrite）用户手动设置的 Content-Type 请求头

也就是说：

如果你的 RequestBody 实现（例如 FormBody, MultipartBody, 或自定义 RequestBody）重写了 contentType() 方法并返回了非 null 值（如 "application/x-www-form-urlencoded"），
那么 BridgeInterceptor 就会无视你在应用拦截器中设置的 Content-Type，强制使用 RequestBody 提供的值。

这正是你观察到的现象：

HttpLoggingInterceptor（在 BridgeInterceptor 之前执行）能看到你设置的 header；
ChuckerInterceptor（默认作为应用拦截器添加，位于 BridgeInterceptor 之后）看到的是已被覆盖/清除后的请求 —— 因此 Content-Type 消失，而 Content-Type2 等非标准头得以保留。

正确解决方案

✅ 方案一：改用 Network Interceptor（推荐）

网络拦截器在 BridgeInterceptor 之后、ConnectInterceptor 之前执行，因此可覆盖其写入的 Content-Type：

Codex Auth Cleaner

一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。

下载

val client = OkHttpClient.Builder()
    .addInterceptor(HeadersInterceptor()) // 应用拦截器（仍可保留，但不用于 Content-Type）
    .addNetworkInterceptor { chain ->
        val originalRequest = chain.request()
        // 强制重写 Content-Type（此时 BridgeInterceptor 已执行完毕）
        val modifiedRequest = originalRequest.newBuilder()
            .header("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8")
            .build()
        chain.proceed(modifiedRequest)
    }
    .addInterceptor(chuckerInterceptor)
    .build()

⚠️ 注意：使用 header()（而非 addHeader()）可确保替换而非追加，避免重复 header。

✅ 方案二：控制 RequestBody 的 contentType

如果你使用的是 Retrofit，并通过 @FormUrlEncoded 或 ScalarsConverterFactory 发送表单数据，请确认：

@FormUrlEncoded 方法底层使用 FormBody，其 contentType() 返回 application/x-www-form-urlencoded → BridgeInterceptor 会据此设置 header，你的手动设置被忽略；
若你希望完全自定义 Content-Type（如带 charset=UTF-8），应避免依赖 @FormUrlEncoded，改用 @Body + 手动构造 RequestBody，并返回 null 的 contentType()：

// 自定义无 contentType 的 RequestBody（绕过 BridgeInterceptor 覆盖）
val body = object : RequestBody() {
    override fun contentType(): MediaType? = null // 关键：返回 null
    override fun writeTo(sink: BufferedSink) {
        sink.writeUtf8("key1=value1&key2=value2")
    }
}

此时 BridgeInterceptor 检测到 contentType() == null，就不会写入 Content-Type 头，你应用拦截器中的 addHeader() 才能生效。

❌ 不推荐的做法

在应用拦截器中反复 addHeader()：无效，会被后续 BridgeInterceptor 覆盖；
修改 ChuckerInterceptor 源码或禁用 BridgeInterceptor：破坏 OkHttp 合规性，极易引发兼容性问题。

总结与最佳实践

场景	推荐做法
需要精确控制 Content-Type（含 charset 参数）	使用 @Body + 自定义 RequestBody 并返回 null 的 contentType()
快速修复现有 @FormUrlEncoded 接口	改用 addNetworkInterceptor 强制重写 header
调试 header 行为	始终用 HttpLoggingInterceptor（Level.HEADERS 或 BODY）验证拦截器执行顺序