com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'password': was expecting ('true', 'false' or 'null')

at [Source: java.io.PushbackInputStream@d3211c6; line: 1, column: 10]

以上為主要報錯內(nèi)容，開始進入檢查，走起。

使用postman單獨調(diào)用該feign正常，確定應該是調(diào)用方參數(shù)封裝問題

檢查調(diào)用方參數(shù)與被調(diào)用方參數(shù)是否一致，檢查后是一致的，這就有點坑爹了。

啟動服務進入debug，嗯，miamiamia,斷點逐一進入，feign調(diào)用意料之中的報錯。

檢查調(diào)用方請求頭設置，application/json，確認，沒毛病。

有點頭大了檢查git修改記錄，貌似也沒啥問題。

回想最近是否有組件修改，想起來了，昨天做了feign調(diào)用請求頭轉(zhuǎn)發(fā)實現(xiàn)了RequestInterceptor接口進行了請求頭的一些處理，debug進斷點看一下是否請求頭被篡改了，打印restTemplate中請求頭信息，application/json，沒毛病再往下看，看到問題了。

該代碼修改請求參數(shù)

因為項目要做多租戶改造，時間比較緊張，這個組件網(wǎng)上找了個測了一下可用就發(fā)上去了，結(jié)果效果十分感人，看了有一會

參考了簡書里的地址傳送門

考慮到使用這種方式要修改為信號量的模式，并沒有完全參考上面那位作者的做法，而是繼承了HystrixConcurrencyStrategy進行了自定義了隔離策略，改動量小一點，畢竟時間緊張，這是個一聽就讓人有種淡淡的憂傷的話