简介这是一套面向.NET开发者的钉钉企业应用集成资料包围绕办公APP的企业级接口对接场景提供SDK、JSAPI接口与TOP接口调用示例适合需要快速实现钉钉免登、消息推送、通讯录同步等功能的C#工程师。项目结构清晰business层封装业务逻辑与接口调用config集中配置corpid和corpsecretmode存放请求/响应实体JsAPI.aspx演示前端JSAPI调用方式便于按需扩展新接口。压缩包共459个文件主要由dll、js、xml、cs、config、aspx等组成dll为运行依赖库cs与aspx为源码和页面config为配置项整体约31.25MB层级分明。已有1759人学习下载资料包含可直接运行的demo、开发文档及SDK并附带NuGet包与项目工程文件能帮助开发者降低钉钉二次开发门槛快速搭建可用原型。1. .NET 接入钉钉先认清 demo 和你真实需求之间的距离很多 .NET 团队第一次接触钉钉开放平台路径几乎都一样搜到一份 .NET 钉钉 demo下载、配置 AppKey、跑通然后发现“能发消息了”但离真正接入业务系统还差一大截。我见过不少项目卡在同一组问题上AccessToken 没做缓存导致频繁被限流、回调地址验签总是失败、事件订阅收不到推送、权限点申请了却依然报错。这份标题背后真正的需求其实不是“跑通一个 demo”而是“用 .NET 把钉钉的组织架构、消息触达、审批事件接入自己的业务系统并且能稳定运行”。这篇文章不打算做成 SDK 文档复述而是按我接模拟项目X时的完整思路拆开讲先选对应用形态再跑通最小链路然后把回调、权限、限流这些坑提前排掉最后把 demo 改造成能上线的工程代码。适合三类人第一次接钉钉的 .NET 后端开发、需要从零搭建企业内集成通道的技术负责人、以及被“demo 能跑但上线就翻车”折磨过的维护者。2. 选对应用形态企业内部应用、机器人还是 H5 微应用2.1 三种常见应用形态与选型判断钉钉开放平台上的应用形态直接决定你后续拿到的凭证类型和接口权限范围。很多 demo 用的是“自定义机器人”的 Webhook 地址只需要一个 access_token 就能往群里推消息但它做不了组织架构读取也收不到审批事件。我见过有项目一开始图省事用机器人后面要同步通讯录时发现路被堵死只能重建应用再改一遍代码。企业内部应用是大多数 .NET 集成场景的默认选择。它组织在开发者后台的“企业内部应用”目录下创建后拿到 AppKey、AppSecret 和 AgentId 三件套。AppKey 和 AppSecret 用来换 AccessTokenAgentId 用来定位“这个应用挂在哪个组织下”发工作通知时必填。第三方应用则是服务商形态要上架到应用市场审核流程长普通企业用不到可以先不碰。H5 微应用是另一个容易混淆的点。它本质上是一个网页应用通过钉钉容器内的 JSAPI 拿到用户身份适合做审批表单、移动端管理页面这类要嵌在钉钉工作台里的场景。如果你只是想把现有系统上的待办消息推给员工或者读取考勤、审批数据那是企业内部应用 服务端 API 的活跟 H5 微应用没关系。选型判断标准我一般就三条。第一要不要在钉钉工作台里展示页面要就做微应用不要就做纯服务端应用。第二要不要主动触达用户要就发工作通知走企业内部应用的消息接口。第三要不要被动的接收业务事件比如审批结果、考勤打卡要就必须配置事件订阅回调或 Stream 模式。2.2 创建企业内部应用的配置清单在开发者后台手动创建应用并不复杂但有几个配置项容易漏漏了后面跑 demo 时会很困惑。逐个说。应用名称和图标随便填真正重要的是“服务器出口IP”。这个配置项决定钉钉网关是否信任你的请求来源如果填了只有列表里的 IP 才能调用接口。本地调试时 IP 会变我一般先不填等功能开发完、部署到固定服务器后再加上。AppKey 和 AppSecret 创建后立即能看到其中 AppSecret 只完整显示一次之后就只能重置复制时记得别带空格和换行。AgentId 在应用详情页里能看到发工作通知时用的就是它。有人在 demo 里把 AgentId 和 AppKey 混填结果一直报“无权限”。这两个东西不是一回事AppKey 是应用的身份标识AgentId 是应用在组织内的实例标识。权限点配置是这里最值得花时间的一步。消息发送对应“企业内部应用消息发送”权限读取通讯录对应“通讯录只读”权限读取审批对应“审批实例详情”权限。每个权限点对应一组 API 的访问许可没申请就调用返回的错误码通常是“无权限”或“Forbidden”。下面用一个表格整理我每次创建应用都会核对的项目配置项取值来源常见错误AppKey应用凭证与 AppId 混淆AppSecret应用凭证复制时带空格或换行符AgentId应用详情误填成 AppKey服务器出口 IP应用配置本地调试忘关换网后被拒权限点权限管理只申请没等生效或申请错 API2.3 权限点看起来开通了实际还没生效权限点这个环节我用“看似开通、实则没生效”来形容。某公司第一次接审批事件我在后台把“审批实例详情”权限勾上代码里也写了读取审批数据的逻辑上线当天调用接口却返回无权限。去后台看权限点状态是“已开通”但接口就是拒绝。后来查官方文档里的权限说明才发现部分权限点申请后需要应用发布或审核后才真正生效企业内部应用虽然免审核但新申请的权限存在一个生效等待窗口这个窗口从几分钟到几小时不等。当时我勾上权限后立刻去调接口自然被墙。处理办法是申请权限点后不要急着写调用代码先在开发者后台的“权限管理”页面确认状态为“已生效”再继续。如果状态一直停在“申请中”检查是不是有企业管理员审批环节没走完。另外同一权限点可能对应多类接口比如“通讯录只读”下还分“用户详情”“部门列表”等子项只勾父项不勾子项调用子接口照样失败。这个小坑直接改变了我之后的开发节奏先配置权限再去写代码而不是并行推进。代码写完了权限没生效排查起来很耗时间而且接口返回的错误信息经常是“无权限”不会告诉你具体缺哪个子权限只能逐项核对。3. 从零跑通最小 demo获取 Token 到发送一条工作通知3.1 先别引 SDK用最朴素的 HTTP 请求确认链路我接钉钉时的习惯是先用最原始的 HTTP 请求把链路打通再考虑要不要引 SDK。原因很简单SDK 封装层会掩盖接口本身的请求细节一旦出现问题你很难分清是参数写错、接口路径过期还是 SDK 内部处理逻辑有偏差。先裸调一次接口能确认网络、凭证、权限点这三层都没问题。最小链路的起点是获取 AccessToken。用 AppKey 和 AppSecret 换 Token 的接口路径是固定的请求成功后返回的 JSON 里包含 access_token 和 expires_in 两个字段expires_in 通常是 7200 秒。这一步如果返回错误优先检查 AppSecret 是否复制完整或者服务器时间是否与标准时间偏差过大。下面是 .NET 里最朴素的调用代码用 HttpClient 直接请求不经过任何 SDKusing System.Text.Json; public class DingTalkTokenClient { private readonly HttpClient _httpClient; public DingTalkTokenClient(HttpClient httpClient) { _httpClient httpClient; } public async Taskstring GetAccessTokenAsync(string appKey, string appSecret) { // 钉钉开放平台的 Token 接口GET 请求 var url $https://oapi.dingtalk.com/gettoken?appkey{appKey}appsecret{appSecret}; var response await _httpClient.GetFromJsonAsyncJsonElement(url); var errcode response.GetProperty(errcode).GetInt32(); if (errcode ! 0) { var errmsg response.GetProperty(errmsg).GetString(); throw new InvalidOperationException($获取Token失败: {errmsg}); } return response.GetProperty(access_token).GetString(); } }这段代码里的 URL 是钉钉开放平台的固定网关地址AppKey 和 AppSecret 通过查询字符串传参。返回结果先检查 errcode非零表示失败这里可以看到具体的错误信息比如“签名错误”或“无效的 appkey”。GetFromJsonAsync 直接反序列化成 JsonElement避免为一个接口单独定义 DTO最小 demo 阶段足够用。3.2 用 .NET 封装一个 TokenProvider缓存与失效补偿裸调接口确认链路没问题后下一步就是把 Token 获取逻辑封装成服务。这一步的必要性来自钉钉的限流策略Token 接口的调用频率有严格限制如果每个请求都现拿 Token开发时还好上线后稍微有点流量就会被限流接口直接报错。正确做法是全局缓存 Token在过期前复用过期后才重新获取。缓存逻辑有几个细节值得注意。第一expires_in 是 7200 秒但建议提前几分钟过期比如缓存 7100 秒避免 Token 正好在请求发起瞬间失效。第二多实例部署时每个实例各自缓存一份 Token 没问题因为钉钉允许同一 AppKey 存在多个有效 Token互相不冲突。第三要处理“缓存里有过期 Token但新请求刚好赶上并发刷新”的情况用锁保证只有一个请求去刷新 Token。我一般会写一个 TokenProvider 服务把所有细节封装在里面业务代码只调一个 GetTokenAsync 方法public class DingTalkTokenProvider { private readonly HttpClient _httpClient; private readonly string _appKey; private readonly string _appSecret; private readonly SemaphoreSlim _syncLock new(1, 1); private string? _cachedToken; private DateTime _expireTime; public DingTalkTokenProvider(HttpClient httpClient, string appKey, string appSecret) { _httpClient httpClient; _appKey appKey; _appSecret appSecret; } public async Taskstring GetTokenAsync() { // 缓存未过期直接返回 if (_cachedToken ! null DateTime.UtcNow _expireTime) { return _cachedToken; } // 并发场景下只允许一个请求去刷新 Token await _syncLock.WaitAsync(); try { if (_cachedToken ! null DateTime.UtcNow _expireTime) { return _cachedToken; } var url $https://oapi.dingtalk.com/gettoken?appkey{_appKey}appsecret{_appSecret}; var response await _httpClient.GetFromJsonAsyncJsonElement(url); if (response.GetProperty(errcode).GetInt32() ! 0) { throw new InvalidOperationException( response.GetProperty(errmsg).GetString()); } _cachedToken response.GetProperty(access_token).GetString(); var expiresIn response.GetProperty(expires_in).GetInt32(); // 提前 100 秒过期避免边界失效 _expireTime DateTime.UtcNow.AddSeconds(expiresIn - 100); return _cachedToken; } finally { _syncLock.Release(); } } }SemaphoreSlim 是这里的关键它保证即使有十个并发请求同时发现缓存过期也只有一个请求会真正调用 Token 接口其余请求等待锁释放后直接复用新缓存。提前过期时间我设成 100 秒这个值不是钉钉官方建议是实践经验减少了边界情况下的 401 错误次数。3.3 发送工作通知的完整代码与参数说明Token 解决了接下来就是最常用的场景给指定员工发一条工作通知。工作通知区别于群机器人消息它出现在员工的“工作通知”会话里不受群成员限制可以做审批提醒、待办提醒、任务通知这类一对多的触达。发送工作通知的接口路径需要带 access_token 参数请求体里要填 agent_id、userid_list 和 msg。其中 userid_list 是在钉钉里联系人的唯一标识不是手机号也不是工号是从通讯录接口里拿到的。我的最小发送示例长这样public class WorkNotificationService { private readonly DingTalkTokenProvider _tokenProvider; private readonly string _agentId; private readonly HttpClient _httpClient; public WorkNotificationService( DingTalkTokenProvider tokenProvider, string agentId, HttpClient httpClient) { _tokenProvider tokenProvider; _agentId agentId; _httpClient httpClient; } public async Tasklong SendTextAsync(string userId, string content) { var token await _tokenProvider.GetTokenAsync(); var payload new { agent_id long.Parse(_agentId), userid_list userId, msg new { msgtype text, text new { content } } }; // 发送工作通知的接口POST 请求 var url $https://oapi.dingtalk.com/topapi/message/corpconversation/asyncsend_v2?access_token{token}; var response await _httpClient.PostAsJsonAsync(url, payload); var result await response.Content.ReadFromJsonAsyncJsonElement(); if (result.GetProperty(errcode).GetInt32() ! 0) { throw new InvalidOperationException( result.GetProperty(errmsg).GetString()); } // 返回 task_id用于后续查询消息送达状态 return result.GetProperty(task_id).GetInt64(); } }这里有几个容易踩的细节。agent_id 是数值类型但配置项里拿到的是字符串要先转成 long。userid_list 支持传多个用户用逗号分隔最小示例先传一个。接口返回的 task_id 很重要它代表这条消息在钉钉侧的投递任务编号可以用来查“是否送达、是否已读”商用场景下一定要存下来。文本消息只是最小验证实际业务里更多用 markdown 消息。markdown 消息的 msgtype 是 markdown额外多一个 title 字段用于在通知列表里显示的标题content 字段则支持 Markdown 语法。3.4 引入 SDK 的时机与取舍钉钉官方对 .NET 的 SDK 支持不算一等公民官方文档里的示例主要面向 Java、Python、Node.js.NET 更多靠社区封装的 SDK 或者自己维护 HTTP 调用。我的取舍标准是这样的如果项目里只用到两三个稳定接口自己封装就够了引入 SDK 反而多一层依赖如果接口调用面很广比如通讯录、审批、考勤、文件一起接那用一套封装好的 SDK 能省掉大量重复的 URL 拼接和参数序列化。不过引 SDK 之前要确认两件事。第一SDK 是否还在维护最近更新时间如果超过一年就要谨慎。第二SDK 对异步的支持怎么样我见过有些封装只提供同步方法在 ASP.NET Core 里用起来会有线程阻塞问题。另外建议不要把 SDK 的请求对象直接透传给业务层先用一个接口定义自己的方法签名内部再转成 SDK 对象这样以后换 SDK 不用改业务代码。引 SDK 的正确姿势是先写好接口抽象再实现public interface IDingTalkMessageSender { Tasklong SendWorkNotificationAsync(string userId, string content); } public class OfficialSdkMessageSender : IDingTalkMessageSender { // 内部调用社区SDK或官方封装业务层只依赖 IDingTalkMessageSender public Tasklong SendWorkNotificationAsync(string userId, string content) { // 这里用SDK内部的Client构建请求 throw new NotImplementedException(); } }抽象接口的意义在于隔离。钉钉开放平台一年内可能会更新接口协议或调整域名有了这层隔离升级 SDK 时只需要改一个实现类业务代码不用动。这也是我从“demo 能跑”到“系统能维护”之间迈出的关键一步。4. 事件回调与 Stream 模式让应用从“请求”走向“响应”4.1 事件订阅的两种接入方式对比前面聊的都是主动调用接口拿数据、发消息。但真实业务里大量场景是反过来的员工提交了一个审批钉钉需要把审批结果推给你有人在工作通知里点了“同意”按钮你要收到这个点击事件。这种“被动接收”的机制在钉钉里叫事件订阅。事件订阅的接入方式目前有两种。第一种是传统的 HTTP 回调模式你在开发者后台配置一个公网可达的 URL钉钉把事件 POST 到这个地址。第二种是 Stream 模式应用在本地发起一个长连接钉钉通过这个连接把事件推送过来完全不需要公网回调地址。对比下来Stream 模式对 .NET 开发者更友好。本地调试 HTTP 回调时最头疼的就是地址暴露问题Stream 模式天然解决了这个痛点。它在代码里创建一个客户端客户端处理连接、心跳、重连你的代码只要注册事件处理函数。两种方式的核心处理逻辑是一样的区别只在于传输层。4.2 HTTP 回调的验签、解密与响应格式如果你需要用 HTTP 回调模式验签和解密是绕不开的一道坎。钉钉推送到回调地址的数据不是明文是一个带加密字段的 JSON 包你要先校验签名再解密出真正的业务数据。很多团队第一次接回调时都在这一步翻车网上查到的说法也各不相同有的说验签用 AES有的说用 RSA其实这是两套体系入口 URL 配置不同加解密方案也不同最稳妥的做法是以开发者后台的“事件订阅”页面提示为准。我用一个通用的处理框架来说明这类验签逻辑的套路public async TaskIActionResult HandleCallbackAsync(...) { // 1. 从请求体中读取JSON解析出 signature, timestamp, nonce, encrypt 四个字段 // 2. 用 token timestamp nonce 按固定规则拼接计算签名 // 3. 与请求里的 signature 比较不一致则直接拒绝 // 4. 验签通过后用 AES 密钥解密 encrypt 字段 // 5. 得到明文 JSON从 eventType 字段判断事件类型 // 6. 处理业务逻辑返回加密后的 success 字符串作为响应 return new ContentResult { Content success }; }验签失败有九成是这几个原因服务器时间与标准时间偏差超过 5 分钟参与拼接的字段顺序与官方文档要求不一致解密时用的 AES 密钥不是从配置页复制的原始字符串而是经过二次编码。所以我调试回调的第一动作永远是先打印当前服务器时间再和请求里的 timestamp 比较秒级偏差内才继续查后面的逻辑。另一个容易忽略的点是响应格式。钉钉回调要求你在处理完业务后返回固定格式的响应代表“我收到了”如果响应内容不对钉钉会认为推送失败然后按策略重试。重试会造成业务数据的重复处理所以回调处理函数里必须要做幂等按事件 ID 或消息 ID 去重这部分在最后一章单独说。4.3 Stream 模式的本机调试体验Stream 模式接入后本地开发的体验提升非常明显。不需要公网地址、不需要配置域名白名单、不需要担心回调接口被第三方扫描启动程序后自动建立长连接有事件就直接推过来。我最近接审批事件就一直用 Stream 模式调试。连接建立后的代码结构大概是这样的// 创建 Stream 客户端并注册事件处理 var client new DingTalkStreamClient(appKey, appSecret); // 订阅审批事件收到推送后执行自定义处理 client.Subscribe(approval, async (eventData) { var approvalResult JsonSerializer.DeserializeApprovalEvent(eventData); await _approvalHandler.HandleAsync(approvalResult); }); // 启动连接内部包含自动重连逻辑 await client.StartAsync();这段代码里的 client 是示意封装不同实现类的 API 名称会有差异但核心步骤一致先创建客户端再注册事件订阅最后启动。启动后通常每 30 到 60 秒会有一次心跳包目的只是保活。如果程序运行一段时间后收不到事件先看日志里有没有重连记录Stream 模式的连接如果 idle 时间过长被服务端断开客户端会自动重连但有些实现里日志级别默认关闭看不到这个过程就会误以为“连上了但没事件”。Stream 模式的订阅事件类型和 HTTP 回调完全一致审批、考勤、通讯录变更都可以订阅。区别在于 Stream 模式在后台的“事件订阅”配置里不需要填写回调地址而是选择“使用 Stream 模式”应用类型和权限点配置与 HTTP 模式共用同一套。4.4 回调处理的服务化拆分回调收到的事件类型会越来越多审批、考勤、群消息、通讯录变更如果都堆在一个事件处理函数里代码会迅速膨胀到无法维护。我习惯做一层事件分发器把“接收事件”和“处理事件”拆开。public class EventDispatcher { private readonly Dictionarystring, FuncJsonElement, Task _handlers new(); public void Register(string eventType, FuncJsonElement, Task handler) { _handlers[eventType] handler; } public async Task DispatchAsync(JsonElement eventData) { var eventType eventData.GetProperty(eventType).GetString(); if (_handlers.TryGetValue(eventType, out var handler)) { await handler(eventData); } } }每个业务模块自己注册感兴趣的事件类型比如审批模块注册 approval 相关事件考勤模块注册 attendance 相关事件互不干扰。新接入一个事件类型时不影响已有逻辑。这种分发结构配合 Stream 模式让整个事件接收链路变得清晰可控排查问题时也只需要看对应 handler 的日志。5. 集成踩坑排查五个高频问题与定位思路5.1 现象一Token 刚跑通就被限流现象是最小示例跑通了但连续运行几分钟后接口开始报错错误信息提示“请求频率超过限制”。我当时第一反应是钉钉限制太严格后来才发现问题出在自己的代码上每个请求都重新调用 Token 接口没有缓存。限流阈值远低于正常业务需求量高频获取必然被限制。原因是 AccessToken 是全局共享凭证钉钉侧会对获取动作单独限流而不是对整个 API 调用限流。解决方法是把 Token 获取逻辑统一收敛到一个带缓存的 Provider 里业务逻辑只调 Provider 拿缓存值。上线前检查的标准是日志里获取 Token 的调用频率应该是分钟级甚至小时级一次而不是请求级一次。5.2 现象二发消息提示“无权限”但权限点确实申请了现象是发送工作通知返回“无权限”去开发者后台看权限点状态是“已开通”。这个坑在 2.3 节里提过本质是权限点申请后有生效延迟企业内部应用虽然免审核但“已开通”和“已生效”之间有窗口期。延迟从几分钟到几小时不定必须在权限管理页面看到“已生效”再继续调接口。另一个隐蔽原因是发消息接口要的应用权限是“企业内部应用消息发送”但有些项目实际用的是“群机器人消息发送”权限两者看着相似接口路径完全不同。排查时不只要看权限点是否生效还要核对代码里调用的接口路径对应的是哪类权限。5.3 现象三回调验签总是失败现象是回调收到请求后在验签环节直接拒绝日志里没有业务数据。这个问题被很多人称为“玄学”因为代码看起来和文档一致但就是验不过。我排查下来原因基本集中在两个点服务器时间偏差和密钥复制问题。钉钉回调验签依赖服务器时间偏差超过一定阈值直接失败。用 NTP 校准时间后问题通常会消失。密钥复制问题则隐蔽得多AppSecret、Token、AESKey 这三个值在复制过程中如果带入不可见字符配置页里看不出问题但实际参与计算的值已经变了。排查方法是把配置值输出成十六进制看末尾有没有多余字符。5.4 现象四Stream 连接正常却收不到任何事件现象是程序启动日志显示连接建立成功心跳正常但钉钉后台触发了事件后程序没有任何反应。这个问题的原因通常是事件订阅没配置对Stream 模式连接成功只代表通道建立了但你没有在开发者后台订阅对应的事件类型。解决方法是去开发者后台“事件订阅”页面确认订阅列表看是否包含你期望接收的事件。比如订阅了“审批任务开始”但没订阅“审批任务完成”完成事件就不会推过来。另外订阅事件需要对应权限点如果权限没生效订阅列表存在但推送依然不会来。5.5 现象五接口返回成功消息却延迟严重现象是发送工作通知接口返回正常task_id 也拿到了但用户几分钟后才收到消息。这个问题的根源通常不在代码而在于钉钉侧的消息投递机制工作通知的投递队列在高并发时有优先级和限流重要通知和普通通知的投递优先级不同。解决思路是区分消息优先级紧急通知走应用内弹窗或电话提醒这类即时通道一般通知接受延迟。另外检查是否有多个环境共用同一个应用例如测试环境和线上环境指向同一个 AgentId两边同时发消息会互相排队这种问题在接口返回上完全看不出来只能通过消息量对比定位。6. 把 demo 改造成能上线的工程Token 治理、幂等与日志钉钉集成从“能跑”到“能上线”中间隔着一个工程化改造。这个改造其实就三件事Token 治理、事件处理幂等、关键日志留痕。Token 治理在 3.2 节已经做了这里再补一条多实例下的处理策略。多个实例各维护一份 Token 是允许的但不要让每个实例单独刷新而是用一个独立的令牌刷新标记比如数据库或分布式缓存里存一个刷新状态没有拿到状态的实例直接复用旧 Token避免流量高峰时所有实例同时刷新。小型项目可以不做这一步但部署了三个以上实例时要考虑。事件处理幂等是上线前必须补齐的。钉钉回调有重试机制同一事件可能推送不止一次如果不做去重审批结果会被重复入库如果下游有发送短信或邮件之类的动作用户会收到重复通知。幂等的实现方案有很多我常用内存集合加过期清理适合单实例public class EventIdempotency { private readonly HashSetstring _processedIds new(); private readonly TimeSpan _expiration TimeSpan.FromHours(24); public bool TryMarkProcessed(string eventId) { // 已处理过则返回 false调用方跳过重复业务 if (_processedIds.Contains(eventId)) { return false; } _processedIds.Add(eventId); // 异步清理过期记录避免集合无限增长 _ Task.Run(async () { await Task.Delay(_expiration); _processedIds.Remove(eventId); }); return true; } }这个方案按 eventId 去重24 小时后自动清除保证同一事件在一天内的重复推送只会触发一次业务处理。多实例部署时要把 HashSet 换成分布式存储比如 Redis 加过期键逻辑不变。日志方面我会要求每个关键链路都打点Token 获取结果、消息发送返回的 task_id、事件推送的 eventId、验签成功或失败。这些日志是线上排查的唯一抓手尤其钉钉这类外部依赖出问题时你连不进去调试只能靠日志还原现场。最后说一个我自己的习惯。早年接钉钉时我直接在业务代码里散落着好几个 HttpClient每个方法各调各的 Token 接口上线第一天就被限流。后来我给自己定了一条规矩凡是接外部开放平台第一件事永远是封装 Token 和 HttpClient而不是先写业务逻辑。这个习惯帮我躲过了后面许多可以预见的坑。钉钉的 .NET 集成不算难难的是把细节守到位该缓存的缓存该去重的去重该打日志的打日志。希望你按这个顺序做下来能少走一些我走过的弯路希望帮到你。本文还有配套的精品资源点击获取