restsharp发xml请求需显式设requestformat为xml、用addbody传无bom的utf-8字符串、手动addheader设content-type为text/xml；禁用application/xml；优先用postasync而非executeasync；避免中文乱码需确保无bom。
RestSharp 怎么发 XML 请求体
RestSharp 默认不自动处理 XML 请求体，直接传字符串或 XmlDocument 都可能被忽略或序列化成空内容。关键不是“怎么写”，而是“怎么绕过默认 JSON 行为”。
- 必须显式设置
RequestFormat为RestSharp.DataFormat.Xml（哪怕你根本没用到序列化器） - 请求体必须用
AddBody()传原始字符串，且不能带 BOM；传XmlDocument或XElement会触发内部 XML 序列化逻辑，但 RestSharp 的 XML 序列化器极弱，不支持自定义命名空间、编码、根节点名等 - 手动设置
Content-Type：用AddHeader("Content-Type", "text/xml; charset=utf-8")，别依赖自动推断
示例：
var client = new RestClient("https://api.example.com");
var request = new RestRequest("submit", Method.Post);
request.RequestFormat = DataFormat.Xml;
request.AddHeader("Content-Type", "text/xml; charset=utf-8");
request.AddBody(@"<?xml version=""1.0"" encoding=""utf-8""?><Order><Id>123</Id></Order>");
为什么 Content-Type 设成 application/xml 就失败
很多 XML 接口实际只认 text/xml，尤其老系统或基于 Java Axis/CXF 的服务。设成 application/xml 后请求能发出去，但服务端直接返回 415 Unsupported Media Type。
-
text/xml是 XML 最早的 MIME 类型，兼容性远高于application/xml - 某些网关（如 Azure API Management、Nginx with certain modules）会根据
Content-Type做预检或重写，application/xml可能被拦截或转义 - RestSharp 内部对
application/xml有隐式处理逻辑（比如尝试加Accept: application/xml），反而干扰原始意图
PostAsync() 和 ExecuteAsync() 选哪个
用 PostAsync() 更安全。它强制走 POST 流程，而 ExecuteAsync() 在未指定 Method 时默认 GET，容易误发空体请求。
-
PostAsync()自动设Method.Post，且返回Task<irestresponse></irestresponse>，便于 await -
ExecuteAsync()要求你手动传Method.Post，漏写就变成 GET，接口返回 405 或静默失败 - 如果服务端要求保持连接（如长 XML 处理），
PostAsync()更易配合CancellationToken控制超时
别写：client.ExecuteAsync(request)；写：await client.PostAsync(request)。
中文乱码和 UTF-8 BOM 导致 500 错误
XML 字符串里含中文时，如果用记事本保存再复制进来，大概率带 BOM（EF BB BF）。服务端 XML 解析器一读就报“XML declaration not at start of document”之类错误，HTTP 状态码常是 500 而非 400，非常误导。
- 用 Visual Studio 或 VS Code 编辑 XML 字符串，保存时选 “UTF-8 without BOM”
- 运行时拼接 XML？用
new UTF8Encoding(encoderShouldEmitUTF8Identifier: false)构造字符串，避免隐式加 BOM - 调试时用
request.Body打印字节：检查前 3 字节是不是EF BB BF—— 是就删掉
这个点藏得深，查半天网络或证书，最后发现是编辑器多写了三个字节。
