不使用Interceptor为单个Retrofit请求添加OAuth1认证头的实现方案

你之前的请求头修改完全不生效，本质是违反了OkHttp的不可变对象设计约定：
OkHttp的Request、Headers都是设计为不可变的值对象，你调用call.request().headers.newBuilder().add(...)时，只是基于原始Headers临时生成了一个新的Headers实例，这个实例既没有被绑定到任何Request对象上，更没有替换Call内部持有的原始请求，整个生成流程没有任何副作用，自然发出去的请求永远读不到你添加的头。

Retrofit生成的Call对象自带newBuilder()构造方法，允许你在不改动底层共享OkHttp客户端的前提下，完全复制原Call、自定义替换内部持有的Request，完全适配你单请求鉴权、不启用全局拦截器的场景。
正确代码流程如下：

// 1. 拿到Retrofit生成的原始Call和对应原始请求
val originalCall = api.getRecentTweetsV1("$query -filter:replies -filter:retweets")
val originalRequest = originalCall.request()

// 2. 基于原始无认证头的请求完成OAuth1签名，生成合规的Authorization头值
// 注意：签名必须在添加Auth头之前计算，否则会导致签名校验失败
val oauth = Oauth1Signing.Builder()
    .consumerKey(consumerKey)
    .consumerSecret(consumerSecret)
    .accessToken(token)
    .accessSecret(tokenSecret)
    .build()
val authHeaderValue = oauth.signRequest(originalRequest)

// 3. 基于原Call复制出带认证头的新Call
val signedCall = originalCall.newBuilder()
    .request(
        originalRequest.newBuilder()
            .addHeader("Authorization", authHeaderValue)
            .build()
    )
    .build()

// 4. 执行带签名的请求
response = signedCall.execute().body()

• 整个流程完全不修改共享的OkHttp客户端配置，哪怕客户端被其他无鉴权要求的业务复用，也不会出现全局头污染的问题
• 不需要在OkHttp客户端初始化阶段就传入OAuth1密钥，完全适配你拿到密钥后再动态发起鉴权请求的时序
• 不需要改动原有Retrofit接口的方法签名，依然可以将完整的原始Request传给你的OAuth1Signer做签名计算，不需要调整Signer的入参逻辑

不要尝试通过反射修改Call内部的私有Request字段，这类实现耦合OkHttp内部实现细节，版本升级时极容易出现兼容性问题，用Call自带的newBuilder方法修改是官方推荐的稳定实现路径。

内容的提问来源于stack exchange，提问作者tyczj