在一次接口調試的時候，用postman工具請求的時候返回很正常，但是用代碼去curl請求的時候就超時了，接口參數接收到了，原因找了很久，找到一個博文，最終解決這個問題。
原文：https://www.jianshu.com/p/154c310748db
在通過curl調用對方接口時，發現超時現象很嚴重，於是詢問對方接口人，對方說需要加上：
加上之后發現果然好使了，於是調研了一下該用法。
在使用curl做POST的時候, 當要 “POST的數據大於1024字節” 的時候, curl並不會直接就發起POST請求, 而是會分為2個步驟：
1、發送一個請求, 包含一個Expect:100-continue, 詢問Server使用願意接受數據
2、接收到Server返回的100-continue應答以后, 才把數據POST給Server
但是這樣會有幾個問題：
不是所有的服務器都會正確應答100-continue, 比如lighttpd, 就會返回417 Expectation Failed。
造成延時，客戶端在發送第一次的Expect:100-continue時，需要等待服務器端進行回答之后才發送request body。
如果確定對方的服務器不會拒絕1024個字節以上的POST請求，就可以不使用該方法而且也可以避免以上提到的兩個副作用，解決的辦法就是文章開頭提到的。
關於100 continue
這樣做的目的是：
它可以讓客戶端在發送請求數據之前去判斷服務器是否願意接收該數據，如果服務器願意接收，客戶端才會真正發送數據，如果客戶端直接發送請求數據，但是服務器又將該請求拒絕的話，這種行為將帶來很大的資源開銷。
客戶端行為：
發送了100 continue的客戶端不應該永遠等待服務器端做出回應，超時一段時間之后，客戶端應該直接將實體發送出去。
服務器端行為：
如果服務器端收到了100 continue的請求，它會用100 continue響應或者發送一個錯誤碼。服務端永遠不能向沒有發送100 continue的客戶端發送100 continue。但是有的服務器會這么做。IIS 5 incorrectly sending 100-continue response
如果服務端在還沒發送100 continue響應時就收到了客戶端的body，那么說明客戶端決定開始發送數據了，所以此時服務器端不能再向客戶端發送100 continue。
參考資料：Expect:100-continue