前言
今天，在对接一个第三方平台开放接口时遇到一个很棘手的问题，根据接口文档组装好报文，使用HttpClient发起POST请求时一直超时，对方服务器一直不给任何响应。
发起请求的代码如下：
using (var httpClient = new HttpClient()) { var msg = new HttpRequestMessage() { Content = new StringContent(postJson, Encoding.UTF8, "application/json"), Method = HttpMethod.Post, RequestUri = new Uri(apiUrl), }; // 这里会一直阻塞，直到超时 var res = httpClient.SendAsync(msg).ConfigureAwait(false).GetAwaiter().GetResult(); if (res.StatusCode != HttpStatusCode.OK) { throw new Exception(res.StatusCode.ToString()); } return res.Content.ReadAsStringAsync().ConfigureAwait(false).GetAwaiter().GetResult(); } 异步请求超时取消错误如下：
这种情况首先怀疑对方服务是不是有问题
然而经过确认，对方服务没问题，并且使用将请求的url和报文粘贴到PostMan进行请求，迅速得到返回报文，一切正常。
排除了对方服务的问题，那是我们的代码问题？
可是上面HttpClient发起Post请求的代码写了不知道多少遍，一直都没问题，今天怎么就不行了呢，我敢保证这么写没毛病。
遇到这种情况该如何解决呢？
爬坑过程
遇到这种问题，相比大部分人开始各种参数换来换去，各种库换来换去，可能最终蒙成了。但是这里我相信PostMan可以请求成功，强大的HttpClient一定可以，一定是是哪个参数问题，有经验的老手首先就会想到: 接口的协议中是不是对Header有什么特别的要求，这里查询文档，没有什么特别要求。
控制变量法
既然我们不知道为什么，也猜不到，那就控制变量法去解决。这里能想到的就是抓包，抓取PostMan成功的请求报文以及我们失败的报文，对比差异。
抓包工具使用的是Fiddler
Postman报文：
POST http://xxx.xxx.xxx.xxx:30000/parking/carin/V1 HTTP/1.1 Content-Type: application/json User-Agent: PostmanRuntime/7.29.2 Accept: */* Postman-Token: 14547b64-d8f6-4b0b-9fa9-48c9ec74a8f6 Host: xxx.xxx.xxx.xxx:30000 Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Length: 563 {"data": ...这里省略了具体json内容} HttpClient报文：
POST http://118.31.110.35:30000/parking/carin/V1 HTTP/1.1 Content-Type: application/json; charset=utf-8 Host: 118.31.110.35:30000 Content-Length: 563 Expect: 100-continue Connection: Keep-Alive {"data": ...这里省略了具体json内容} 差异排查
- 因为
body中的内容是一样的，这里就不用对比了。 - 两个请求的Header存在差异，那我们就将差异一个一个抹平。
Content-Type在HttpClient中多了charset=utf-8，这个应该不影响，http协议默认就是utf8。User-Agent在HttpClient中没有，那我们加上一模一样的User-Agent，测试，依旧超时。Accept在HttpClient中没有，抹平，测试，依旧超时。Postman-Token在HttpClient中没有，抹平，测试，依旧超时。Accept-Encoding在HttpClient中没有，抹平，测试，依旧超时。
到这里Postman中有的，我们HttpClient中都有了，竟然还超时，这里虽然已经保证大部分参数都一样了，但是控制变量法要求所有参数都一样，这里还没有保证，因为HttpClient多了一个Expect头，我们还没保证一致。
HttpClient的请求头中Expect: 100-continue在Postman报文中不存在，去掉Expect，测试，成功了！！- 那我们锁定
Expect: 100-continue导致了我们的请求无响应，还原之前所有的抹平操作，仅仅移除Expect: 100-continue，测试，依然成功。
本文为Gui.H原创文章，发布于公众号：dotnet之美，转载注明出处
最终解决前言中的问题，仅仅需要添加一行代码
msg.Headers.ExpectContinue = false; ExpectContinues属性文档：
至此问题解决，控制变量yyds
Expect是什么
参考Expect的定义
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect
Expect 是一个请求消息头，包含一个期望条件，表示服务器只有在满足此期望条件的情况下才能妥善地处理请求。
Expect
规范中只规定了一个期望条件，即 Expect: 100-continue, 对此服务器可以做出如下回应：
100如果消息头中的期望条件可以得到满足，使得请求可以顺利进行的话，417(Expectation Failed) 如果服务器不能满足期望条件的话；也可以是其他任意表示客户端错误的状态码（4xx）。
例如，如果请求中 Content-Length 的值太大的话，可能会遭到服务器的拒绝。
Expect有啥好处
让客户端在发送请求数据之前去判断服务器是否愿意接收该数据，如果服务器愿意接收，客户端才会真正发送数据，如果客户端直接发送请求数据，但是服务器又将该请求拒绝的话，这种行为将带来很大的资源开销。
Expect有啥坑
不是所有的服务器都会正确应答100-continue, 比如lighttpd, 就会返回417 Expectation Failed。
超时的原因
HttpClient默认携带了Expect头，我们请求带上了Expect: 100-continue的话是不会立刻发送body中的报文给服务器，需要服务器需要对Expect: 100-continue做出响应，然而对方服务器不支持Expect当然不能做出响应，在前言说的问题中，也就是HttpClient在等对方服务器响应Expect，然后再发送报文，而对方服务器看来，我们怎么还不发送报文过来，双方都在等数据，最终HttpClient超时~
以上纯属个人理解，有不正确之处，还请指正~
