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：
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）验证拦截器执行顺序 |
最终，请记住：OkHttp 的拦截器链有明确执行顺序（Application → Network → Connect → Call），而 Content-Type 的“消失”本质是协议层自动协商的结果——理解 BridgeInterceptor 的角色，才能真正掌控请求头的生命周期。
