对于大多数 CI/CD 通知场景，直接使用 Webhook 方式更合适，除非你需要发送交互式卡片或管理群成员。
先说结论：CI/CD 流水线主要追求配置简单和发送稳定，Webhook 无需维护 access_token，更适合嵌入脚本。
- 适合：构建结果通知、简单告警、无需用户交互的场景。
- 重点看：Webhook 地址的安全设置（加签或 IP 白名单），防止被滥用。
- 别忽略：SDK 方式需要维护应用凭证和 Token 刷新逻辑，会增加流水线脚本的复杂度。
命令速用版
如果选择 Webhook 方式，在 Linux 环境的 CI/CD 脚本中可以直接使用 curl 发送，无需安装额外依赖。
curl 'https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN' \-H 'Content-Type: application/json' \-d '{"msgtype":"text","text":{"content":"构建成功"}}'若开启了加签安全设置，需要在请求参数中拼接 timestamp 和 sign 签名，具体签名算法需参考官方文档。
为什么会这样
Webhook 本质是一个固定的 HTTP POST 接口，调用方只需要知道地址和安全密钥即可发送消息，状态是无记忆的，适合脚本调用。
SDK 方式通常对应钉钉内部应用或 ISV 应用，需要先通过 appKey 和 appSecret 获取 access_token，该 Token 有有效期，需要脚本处理缓存或刷新逻辑。在 CI/CD 这种一次性执行的环境中，维护 Token 状态会增加不必要的代码量和出错概率。
公开资料中没有看到可靠的量化数据表明两种方式在发送速度上有显著差异，主要区别在于接入和维护成本。
分步处理
1. 创建机器人
在钉钉群设置中找到“智能群助手”，添加自定义机器人。记录生成的 Webhook 地址。
2. 配置安全设置
建议开启“加签”方式。复制-secret，后续请求需要用它计算 HMAC-SHA256 签名。相比 IP 白名单，加签更适合动态 IP 的 CI/CD 环境。
3. 编写发送脚本
在 Jenkinsfile 或 GitLab CI 配置中，调用 curl 或编写简单的 Python/Shell 脚本。若使用加签，需先计算签名再拼接 URL。
4. 配置 SDK（仅当需要复杂功能）
若必须使用 SDK，需在钉钉开放平台创建内部应用，获取 AppKey 和 AppSecret。在代码中引入钉钉 SDK 库，实现获取 Token 和发送消息的逻辑。
怎么验证是否生效
1. 手动触发
在本地终端或 CI/CD 界面手动运行一次发送命令。
2. 观察接收端
检查钉钉群聊是否收到消息，消息内容是否与脚本中一致。
3. 检查返回码
命令执行后，检查 HTTP 响应状态码是否为 200，且返回 JSON 中的 errcode 是否为 0。
常见坑
1. 签名错误
加签模式下，timestamp 和 sign 必须作为 URL 参数拼接，且编码格式需正确，否则会返回签名无效错误。
2. 频率限制
机器人接口有调用频率限制，不要在循环中高频调用，避免被限流。
3. 密钥泄露
Webhook 地址和-secret 等同于密码，不要提交到公共代码仓库。在 CI/CD 平台中将其配置为环境变量。
4. 内容格式
发送 JSON 时确保 Content-Type 为 application/json，且消息体符合钉钉定义的 msgtype 结构，否则可能发送失败。
参考来源
- 钉钉开放平台，自定义机器人接入文档，https://open.dingtalk.com/document/robots/custom-robot-access
- 钉钉开放平台，发送消息接口说明，https://open.dingtalk.com/document/robots/send-robot-messages
原文链接：https://www.zjcp.cc/ask/10654.html