最近有個需求，是對接某個運動APP的Api開放平臺使用者授權業務。文中以兩個API為例：
1、獲取token
場景：使用者在授權⻚頁⾯麵點擊授權後，⻚頁⾯面會跳轉到合作⽅方提供的redirect_url，合作⽅方通過跳轉傳回的code換取token，完成認證和授權。
Header附加引數：Authorization:Basic base64(AppKey:AppSecret) `
注意：Basic後⾯面必須有一個空格。
2、獲取使用者資料
場景：獲取使用者資料接⼝⽤於獲取使用者在APP的使用者資料。
Header附加引數：Authorization:Bearer token
注意：Bearer後⾯面必須有一個空格。
分析從上述API資料裡面分析得出要對接這兩個API需要設定不同的Header資訊，那麼就需要程式碼中支援動態設定header功能。
專案框架由於專案是使用SpringCloud 整合Feign搭建的基礎框架，並且在專案中已經設計了全域性的Header。
通過實現RequestInterceptor介面,完成對所有的Feign請求,設定Header程式碼如下：
@Configurationpublic class FeignClientConfig implements RequestInterceptor { @Value("${token}") private String token; @Override \tpublic void apply(RequestTemplate template) { template.header("token", token); } /*列印feign請求日誌級別*/ @Bean public Logger.Level level() { return Logger.Level.FULL; }}原理：@FeignClient 的代理類在執行的時候，會去使用該攔截器，然後注入到 spring 上下文中，這樣就可以在請求的上下文中新增自定義的請求頭。
優點：所以自定義自己的攔截器
缺點：操作的是全域性的 RequestTemplate，比較難以根據不同的服務方提供不同的 header。
方案一：使用Feign官方方案經過分析得出現在的程式碼是不支援這次需求，那麼專案中既然集成了OpenFeign，可以從這裡入手看看官方是如何解決的。
OpenFeign原始碼地址：https://github.com/OpenFeign/feign
// openfeign 官方文件程式碼示例public interface ContentService { @RequestLine("GET /api/documents/{contentType}") @Headers("Accept: {contentType}") String getDocumentByType(@Param("contentType") String type);}通過上面的官方文件程式碼示例發現不需要那麼麻煩，用原生的@Headers 註解就能解決我們的問題了，新增到程式碼上。
@Headers 程式碼示例
@FeignClient(name = "xxx-feign-service",url = "IP:埠")@Headers({"Authorization: ${token}"}) public interface FeignClient { @RequestMapping(value = "/getToken") String getToken();}使用{token} 可以傳遞動態header屬性。
一番折騰後發現@Headers 沒有生效，在生成的RequestTemplate中，沒有獲取到token值。 然後除錯一下程式碼，發現，ReflectFeign在生成遠端服務的代理類的時候，會通過 Contract 介面準備資料。 而*@Headers* 註解沒有生效的原因是：官方的 Contract 沒有生效：
程式碼如下：
去翻一下springcloud-openfeign在建立 Feign 相關類的時候，使用的是容器中注入的 Contract程式碼如下：
@Bean@ConditionalOnMissingBeanpublic Contract feignContract(ConversionService feignConversionService) { return new SpringMvcContract(this.parameterProcessors, feignConversionService);} public class SpringMvcContract extends Contract.BaseContract implements ResourceLoaderAware { @Override\tpublic MethodMetadata parseAndValidateMetadata(Class<?> targetType, Method method) {\t\t .... // 注意這裡，它只取了 RequestMapping 註解\t\t RequestMapping classAnnotation = findMergedAnnotation(targetType, RequestMapping.class);\t\t ....\t\t parseHeaders(md, method, classAnnotation);\t\t }\t\t return md;\t}我們來總結一下：
1、openfeign本身是支援在方法上使用@Header 註解，來實現自定義header功能。
2、springcloud-openfeign只是集成了openfeign的核心功能，@Headers 註解並沒有被使用。
3、SpringCloud 使用了自己的 SpringMvcContract 來處理請求的相關資源資訊，裡面只使用 @RequestMapping 註解。
也就是被閹割了唄~~~~
方案二：使用 @RequestMapping的 headers 屬性上面提到了第3點可以使用 @RequestMapping 註解中的headers屬性來解決，來試一下。
@FeignClient(name = "xxx-feign-service",url = "127.0.0.1:8080")public interface FeignClient { @RequestMapping(value = "/getToken") String getToken(@Param("token") String token);}經測試SpringCloud 支援@RequestMapping 註解的 header，可以正常獲取頭部資訊。
但是問題來了，很多同學不習慣在類上直接使用 @RequestMapping 註解，有沒有一個全域性管理的地方？也方便程式碼維護呢？
方案三：重寫RequestInterceptor的apply方法
上面提到過通過實現RequestInterceptor介面完成對所有的Feign請求，可不可以在FeignClientConfig檔案裡面統一管理呢？那就需要我們自定義這個類了。具體程式碼如下：
@Configuration@Datapublic class FeignClientConfig implements RequestInterceptor { @Value("${appKey}") private String appkey; @Value("${appSecret}") private String appSecret; private String token; @Bean public RequestInterceptor RequestInterceptor() { return new RequestInterceptor() { @Override public void apply(RequestTemplate template) { String text = appkey+":"+appSecret; String authorization = ""; if(StringUtils.isBlank(token)){ authorization="Basic "+ StringUtil.encode(text); }else{ authorization="Bearer "+ token; } template.header("Authorization", authorization); } }; } /*列印feign請求日誌級別*/ \t@Bean \tpublic Logger.Level level() { return Logger.Level.FULL; }}註釋：根據文中開始部分提到的業務中有兩個API，並且他們的請求Header資訊不一樣，通過重寫RequestInterceptor的apply方法來封裝header值，達到解決動態引數的問題（有心的同學這裡的程式碼可以更加優雅一點兒）。
總結通過尋找解決問題的方法發現SpringMvcContract 是在 parseAndValidatateMetadata 中解決在類上面的 header 的問題，這裡也特別提醒一下各位同學Spring Cloud 並沒有基於Spring MVC 全部註解來做Feign 客戶端註解協議解析，這個是一個不小的坑。這也導致了最開始沒寫想到在feign介面上使用 @RequestMapping來解決問題。
那麼使用@RequestMapping 解決header問題是最簡單也更加原生的方案，通過重寫RequestInterceptor的apply方法來實現可以統一管理頭部資訊，方便後續的維護，兩者各有千秋。