简介RestSharp 106.13.0 编译版压缩包是面向 .NET 开发者的 REST API 客户端类库资源内含最新版 RestSharp.dll 及配套文件支持 netstandard2.0 与 net452 两种目标框架。它针对接口调用中常见的请求构造、自动序列化与反序列化、请求和响应类型检测、多种身份验证方式等痛点提供了开箱即用的封装可大幅简化与 RESTful 服务交互的代码量适用于桌面端、服务端及移动端项目也适合希望学习 HTTP 客户端库设计思路的中高级开发者。压缩包总计八个文件其中三个动态链接库包含核心库及依赖程序集两个 XML 为接口注释文档两个 PDB 为调试符号一个 JSON 记录依赖清单整体体积仅二百五十 KB非常轻量。目前已有四百六十人学习下载。获取后可直接引用动态链接库进行开发对照 XML 文档查阅 API 用法利用 PDB 文件定位更精确的代码行并借助 JSON 检查依赖版本从而省去自行编译和配置的额外工作把更多精力放在业务实现上。1. RestSharp 106.13.0旧 API 线上项目里还能打的 HTTP 类库接手一个老接口服务时对方交付的压缩包里放着一个 RestSharp 106.13.0 的 dll没有源码也没有说明文档。这类场景在真实项目里比想象中多——需要快速联调、改 bug、补接口又不敢贸然升级类库版本。RestSharp 是 .NET 生态里很常见的 HTTP 客户端类库封装了请求、响应、反序列化、认证和文件上传这些样板代码而 106.13.0 恰好是老 API 线的最后一个维护序列版本。对有历史包袱的项目来说这份 dll 比最新版更安全因为新版本把 API 推倒重来旧教程和旧代码全对不上。这篇笔记就把版本差异、引用方式、调用模板和踩过的坑一次说清楚。2. 版本分水岭与依赖边界一份 dll 值不值得信任的三个判断2.1 106 与 107 的分水岭不是版本号变了是 API 风格变了RestSharp 从 v107 开始做了一次大重构底层从 HttpWebRequest 那套迁移到 HttpClient 体系方法命名、参数构造、异步模式全部调整。网上大量教程和博客在讲“new RestRequest(api/order, Method.GET)”这种老写法实际上是 106 时代的语法在 v107 下直接编译不过。新版本里 Method 枚举改成了不加时态的 Get/PostIRestResponse 的 Content 属性也不再有原来的同步语义很多旧代码搬上去要改几十处。106.13.0 属于老 API 线的后期维护版本功能上已经稳定主要修补了一些边界 bug比如 URL 编码、响应头解析这类细节。它的存在意义不是“最新”而是“兼容”。如果你维护的是 2019 到 2022 年之间的 .NET 项目或者课程设计、演示 Demo 是基于老教程写的106.13.0 能让你少改一堆代码。我的判断标准有三个目标框架是否匹配dll 的 TFM 和项目框架要对得上依赖项是否补齐RestSharp 自身不是零依赖序列化、日志、认证组件需要单独装配现有代码风格是哪种写法如果项目里全是 Execute 和 AddParameter107 升级成本远高于收益。这三个条件满足这份 dll 反而是最省事的方案。反过来如果你要开发全新项目没有历史代码包袱那就别用 106直接上 107 甚至更高版本。2.2 目标框架与运行环境先看 TFM 再决定要不要解压dll 和源码不同程序集是面向特定目标框架编译的。RestSharp 106.13.0 一般在 .NET Framework 4.5.2 和 .NET Standard 2.0 两个目标上有发布这意味着项目类型目标框架是否可用说明WinForms / WPF / 老 ASP.NET.NET Framework 4.6.1可用直接引用注意依赖项补齐老 WebForms 项目.NET Framework 4.5.2兼容32 位进程下注意内存.NET Core / .NET 5.NET Core 3.1 / .NET 6可用走 .NET Standard 2.0 通道新 .NET 8 / 9 项目.NET 8不推荐依赖链容易冲突建议直接用新版本如果你拿到 dll 后不确定它面向哪个框架在 Windows 下可以直接右键看文件属性里的“产品版本”和“文件版本”或者在 Visual Studio 里“引用 → 添加引用”后看程序集信息。.NET Framework 项目里最稳妥的做法是先放一个最小控制台项目试引用编译过了再挪进主工程避免一上来就污染大项目。我一般会先做这一步把 dll 拖进一个空白 .NET Framework 4.6.1 控制台项目跑一段最简单的 new RestClient 代码看能不能编译运行。这一步能挡住至少三成的“引用报错”。2.3 依赖边界它不是一个能单文件运行的库RestSharp 106 时代最大的坑是序列化依赖不再内置。早期的 RestSharp 自己带了 JSON 序列化实现后来逐渐把 Newtonsoft.Json 拆到外部让使用方自己管理版本。于是你的包里如果只有 RestSharp.dll大概率会在运行时遇到“未能加载文件或程序集 Newtonsoft.Json”这样的报错。106.13.0 的常规依赖包括 Newtonsoft.Json 以及若干 ASP.NET Core 相关的可选组件。具体版本号以你解压出的 dll 引用元数据为准不要盲信网上的说法。离线环境下手动添加引用时建议把 Newtonsoft.Json.dll 和 RestSharp.dll 放在同一个私有目录里别直接丢到 bin 下方便排查版本来源。依赖补齐的原则是“先查清单再动手”。Visual Studio 里选中引用按 F4 查看属性或者用命令行工具看目标框架和程序集引用比猜版本可靠得多。3. 离线引用与依赖补齐从 rar 解压到第一行可运行代码3.1 解压与添加引用三个容易忽略的动作拿到 dll 压缩包后不要直接双击 dll 就完事。RAR 里通常只有程序集本体但你在项目里引用它之前需要做三件事解压到固定目录、确认依赖项、添加引用并设置“复制本地”。我通常会在解决方案目录下建一个libs文件夹把第三方 dll 集中放进去而不是解压到桌面或者下载目录。这样项目挪到别的机器时引用路径不会断。然后打开 Visual Studio右键项目 →“添加引用”→“浏览”选中解压后的 RestSharp.dll。添加引用后马上检查“引用属性”里的“复制本地”是否为 true。如果是 Web 项目或者服务项目运行目录不一定等于项目输出目录复制本地设为 true 才能保证运行时能找到 dll。# 解压 RAR 并确认内容 unrar e RestSharp-106.13.0_dll.rar ./libs dir ./libs这一步看着简单但很多人栽在“项目换电脑后找不到引用路径”上。把 dll 放在解决方案目录内引用路径用相对路径团队协作时每个人 schema 都一样少很多心智负担。3.2 依赖补齐与 bindingRedirect运行时不报错的关键106 系列的 RestSharp 几乎绕不开 Newtonsoft.Json 的版本协调问题。如果你的项目里已经有其他组件引用了旧版 Json.NET运行时就会上演“版本战争”编译能过启动报错。最常见的做法是加 bindingRedirect。下面这段配置放在 app.config 里把 0.0.0.0 到 13.0.0.0 的重定向到项目实际使用的 13.0.0.0configuration runtime assemblyBinding xmlnsurn:schemas-microsoft-com:asm.v1 dependentAssembly assemblyIdentity nameNewtonsoft.Json publicKeyToken30ad4fe6b2a6aeed cultureneutral / bindingRedirect oldVersion0.0.0.0-13.0.0.0 newVersion13.0.0.0 / /dependentAssembly /assemblyBinding /runtime /configuration这段配置的作用是告诉 CLR不管项目里其他组件引用的是哪个旧版本号统一加载 13.0.0.0 这个版本。oldVersion 的范围要覆盖项目里可能出现的所有旧版本比如 6.0.0.0、9.0.0.0否则还是会炸。如果是 .NET Core 或 .NET 5 项目没有 app.config 这套机制一般靠 NuGet 统一版本或者在 Directory.Build.props 里强制指定版本。离线环境下如果 NuGet 拉不到包就得手动把对应版本的 dll 放进输出目录并确保程序集元数据里的版本号一致。3.3 第一段可运行代码验证 RestClient 是否正常引用配置完成后先跑一段最小验证代码确认 dll 能加载、网络请求能发出using RestSharp; var client new RestClient(https://api.sample.com); var request new RestRequest(health, Method.GET); var response client.Execute(request); Console.WriteLine(response.StatusCode); Console.WriteLine(response.Content);这段代码的逻辑是创建 RestClient 时传入 BaseUrl之后每个 RestRequest 只写相对路径。client.Execute(request)是 106 的同步方法返回 IRestResponse里面的 StatusCode 是 HTTP 状态枚举Content 是响应体原始字符串。注意 106 的 Execute 泛型重载ExecuteT虽然存在但默认序列化行为在复杂 JSON 下不算聪明。如果你只是验证连通性直接用同步版本最省事如果接口响应比较大或者需要超时控制改用 ExecuteAsync 或者带 CancellationToken 的重载防止界面线程卡死。4. 高频调用实操GET、POST、文件上传的参数边界在哪4.1 GET 请求与 URL 占位符AddUrlSegment 比字符串拼接安全GET 接口最常见的需求是把参数拼到 URL 里。新手喜欢用字符串拼接比如orders/ orderId但遇到转义字符、特殊符号时容易翻车。RestSharp 106 推荐用 AddUrlSegmentusing RestSharp; using Newtonsoft.Json; public class Order { public string Id { get; set; } public string CreateTime { get; set; } public decimal Amount { get; set; } } var client new RestClient(https://api.sample.com); // 路径中的 {id} 会被 AddUrlSegment 替换 var request new RestRequest(orders/{id}, Method.GET); request.AddUrlSegment(id, 1024); request.AddHeader(Accept, application/json); var response client.Execute(request); if (response.IsSuccessful) { // 106 的 Content 是原始字符串需要手动反序列化 var order JsonConvert.DeserializeObjectOrder(response.Content); Console.WriteLine(order.Id / order.Amount); } else { Console.WriteLine(HTTP (int)response.StatusCode : response.ErrorMessage); }AddUrlSegment 的行为是把请求路径里大括号包裹的占位符替换成你传的值并且自动做 URL 编码。AddHeader 则负责请求头。这里有个细节Execute不会因为你请求头的 Accept 是 application/json 就自动帮你反序列化所以拿到 Content 后调用 JsonConvert.DeserializeObject 是常见做法。如果不自定义序列化器106 对字段名不做大小写转换。JSON 里是create_time类里写CreateTime反序列化结果就是 null。这个问题在下一章避坑清单里展开。4.2 POST 请求与参数体AddJsonBody 和 AddParameter 的区别POST 是接口联调里最容易写错的环节。RestSharp 106 提供两种提交 JSON 的方式var client new RestClient(https://api.sample.com); var request new RestRequest(orders, Method.POST); request.AddHeader(Authorization, Bearer token); // 方式一AddJsonBody 直接传对象内部走默认序列化器 request.AddJsonBody(newOrder); // 方式二AddParameter 提交已经拼好的 JSON 字符串 request.AddParameter(application/json, jsonString, ParameterType.RequestBody); var response client.Execute(request); if (response.StatusCode System.Net.HttpStatusCode.Created) { Console.WriteLine(response.Headers[Location]); }AddJsonBody的好处是对象序列化这一步交给 RestSharp代码简洁AddParameter的优势是你可以完全控制请求体字符串适合拿现成 JSON 或者需要特殊格式的场景。两者都需要保证服务端期望的 Content-Type 是 application/json只是 AddJsonBody 会自动设置而 AddParameter 需要你在参数里指定。超过 100KB 的 JSON建议先压缩字段或者改走 gzip 编码RestSharp 106 对特大请求体没有做自动优化。4.3 文件上传AddFile 与 multipart/form-data 的组装细节文件上传用 AddFile 就能触发 multipart/form-data 编码var client new RestClient(https://api.sample.com); var request new RestRequest(files/upload, Method.POST); // 参数名 file 需要与服务端约定一致 request.AddFile(file, D:\temp\合同.pdf, application/pdf); request.AddParameter(bucket, contracts); var response client.Execute(request); if (response.IsSuccessful) { Console.WriteLine(上传完成); }AddFile 的第二个参数是本地文件路径第三个参数是 MIME 类型。服务端通过字段名 file 拿到文件流。这里容易踩的坑是 MIME 类型写错或文件名带中文导致服务端保存失败。106 对中文文件名处理不算智能后续版本有改进老版本里建议手动处理文件名比如改成英文或者做 URL 编码。超过 200MB 的文件不建议走 AddFileRestSharp 106 的 multipart 组装是整包进内存的文件一大内存直接飙高。大文件走流式上传不要为难这个老库。4.4 异步与超时避免阻塞 UI 和线程池老项目里常见问题是用同步 Execute 调接口导致 UI 卡死。106 也提供了异步重载var client new RestClient(https://api.sample.com); client.Timeout 15000; // 单位是毫秒15 秒 var request new RestRequest(orders, Method.GET); var response await client.ExecuteAsync(request); Console.WriteLine(response.Content);注意 106 的 Timeout 单位是毫秒不是秒。很多人写成Timeout 30以为 30 秒实际是 30 毫秒直接超时。建议至少 15000 起步并且根据接口耗时调整。另外 106 的 ExecuteAsync 在异步返回时不会自动处理 CancellationToken长时间请求想取消的话要么自己在外部包一层 Task.WhenAny要么升级到 107 用真正的异步 API。这是老库的边界知道就好不要强求。5. 避坑清单106.13.0 最值得记的五个翻车点5.1 反序列化后全是 null命名策略不一致现象Execute 调用成功StatusCode 正常但返回对象的所有属性都是 null而 response.Content 里的 JSON 明明有值。原因服务端返回的字段是下划线风格比如create_time、total_amount而你的 C# 类属性是帕斯卡命名CreateTime、TotalAmount。RestSharp 106 默认的 JSON 解析器不会自动做命名映射Newtonsoft.Json 默认也不做 snake_case 转 PascalCase。解决在属性上加[JsonProperty(create_time)]或者全局配置自定义 ContractResolver。我更推荐前者影响面小不容易误伤其他接口。5.2 Cookie 丢失导致会话失效现象第一个接口登录成功第二个接口紧接着调用返回 401 或者提示未登录。原因RestClient 默认不启用 CookieContainer每个请求都是无状态独立请求服务端种的 Cookie 没有保留下来。解决手动给 RestClient 设置 CookieContainerclient.CookieContainer new System.Net.CookieContainer();注意同一个 RestClient 实例要复用如果你每个请求都 new 一个 RestClientCookieContainer 还是会丢。保持单例或者至少让需要共享会话的请求走同一个客户端。5.3 Timeout 设置完全无效现象接口服务挂起客户端一直转圈Timeout 明明设置了却不生效。原因一个是单位问题106 的 Timeout 是毫秒不是秒设置成 30 等于 30 毫秒直接失败另一个是 HttpWebRequest 底层读流阶段的超时还受 ReadWriteTimeout 影响Timeout 只管到拿响应头的阶段。解决确认 Timeout 至少 1000010 秒并且同步请求如果卡在读取响应流可以再设置client.ReadWriteTimeout 15000。这两个值分开控制调试时先看日志卡在哪一步。5.4 程序集加载失败版本战争现象编译能过运行时抛FileNotFoundException或Could not load file or assembly Newtonsoft.Json, Version...。原因项目里其他组件引用了低版本 Newtonsoft.JsonRestSharp 106.13.0 需要更高版本CLR 加载时按程序集版本匹配失败。解决优先加 bindingRedirect把旧版本号统一重定向到实际版本。如果 bindingRedirect 还搞不定检查是不是手动添加的 Newtonsoft.Json.dll 和目标框架不匹配比如把 .NET Core 版本的 dll 放到了 Framework 项目里。5.5 中文文件名和 URL 编码问题现象上传文件名含中文时服务端收到乱码URL 参数含中文时返回 400。原因106 对非 ASCII 字符的 URLEncode 处理在部分版本里有问题文件上传的 multipart 头里文件名编码也不统一。解决路径参数和 query 参数先手动Uri.EscapeDataString再传进去文件名在上传前改成无中文或转成拼音。不要依赖库内部做编码老版本的实现不如你手动处理稳妥。6. 进阶换序列化器、指数退避与一次抓包验证习惯6.1 用 Newtonsoft.Json 替换默认序列化器如果项目里大量接口都要求 camelCase 或者日期格式化可以给 RestClient 挂自定义序列化器client.AddHandler(application/json, new JsonNetSerializer());public class JsonNetSerializer : RestSharp.Serialization.IRestSerializer { public string Serialize(object obj) JsonConvert.SerializeObject(obj, new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore }); public T DeserializeT(string content) JsonConvert.DeserializeObjectT(content, new JsonSerializerSettings { DateFormatString yyyy-MM-dd HH:mm:ss }); public string[] SupportedContentTypes { get; } { application/json, text/json }; }这样ExecuteT在反序列化时会走你的设置NullValueHandling 和日期格式都能统一控制。6.2 重试与指数退避只对幂等请求重试接口联调最怕 500 和 502重试策略不能瞎写。常见做法是只对幂等 GET 和部分 POST 重试非幂等操作用确认机制var request new RestRequest(orders/{id}, Method.GET); request.AddUrlSegment(id, 1024); int maxRetry 3; for (int i 1; i maxRetry; i) { var response client.Execute(request); if ((int)response.StatusCode 500) break; Thread.Sleep(i * 1000); }6.3 抓包验证习惯从 106 一路用过来我最深的感受是参数对了问题常常出现在请求头和编码上。现在每次联调新接口我都习惯先抓包对比一次看实际发出的 URL、Header、Body 到底符不符合服务端文档而不是盯着返回码猜。这个动作帮我省下大量“玄学”排障时间。从那以后我每次对接新服务都强制走一遍“抓包 → 对比 → 改代码”的流程希望帮到你。本文还有配套的精品资源点击获取