多个项目共用同一个钉钉机器人 webhook 无法由钉钉服务端自动区分来源，必须在发送消息的请求体中由客户端代码显式添加项目标识。
先说结论：Webhook URL 本身不包含来源信息，区分来源完全依赖发送方在消息内容中自定义字段或文本前缀。
- 适合：多个内部系统共用一个告警群，且无法为每个系统单独创建机器人的场景。
- 先准备：统一各项目消息发送代码，在 title 或 text 字段中注入项目名、环境名等标识。
- 验收：发送测试消息后，确认钉钉群内显示的消息内容包含预期的来源标识。
快速处理思路
不需要修改钉钉后台配置，直接调整调用 webhook 的代码 payload。在 markdown 或 text 类型消息中，强制加入项目名称前缀。
POST https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN
Content-Type: application/json
{
"msgtype": "markdown",
"markdown": {
"title": "【项目 A】告警通知",
"text": "#### 【项目 A】服务异常\n- 时间：2023-10-27 10:00\n- 内容：接口超时"
}
}将上述 JSON 中的【项目 A】替换为实际项目名称，多个项目共用 token 时，各自维护自己的标识字符串。
为什么会这样
钉钉机器人 webhook 接口是无状态的 HTTP POST 接口，服务端仅校验 access_token 和签名，不记录发送者身份。
钉钉开放平台的机器人设计逻辑是“消息通道”，而非“应用管理系统”。Webhook URL 中的 access_token 仅代表机器人身份，不代表调用方身份。因此，区分来源的责任在于调用方（Client），而非接收方（DingTalk Server）。如果不主动在消息体中标注，所有消息在群内显示效果完全一致。
分步处理
步骤 1：定义标识规范
确定消息标题或正文开头的固定格式。建议使用方括号包裹项目名，例如【订单系统】、【支付服务】。避免使用容易混淆的缩写。
步骤 2：修改发送代码
在各项目的告警发送模块中，硬编码或读取配置中的项目标识，拼接到消息内容中。如果使用 markdown 类型，修改 title 和 text 字段；如果使用 text 类型，修改 content 字段。
步骤 3：处理安全签名
如果机器人开启了“加签”安全设置，各项目代码必须持有相同的 secret 才能生成正确的 timestamp 和 sign。确保 secret 安全分发，不要硬编码在公开代码库中。
步骤 4：配置频率控制
在客户端代码中增加本地限流逻辑。多个项目共用一个 webhook 会共享钉钉侧的频率限制配额，单个项目突发告警可能阻塞其他项目消息。
怎么验证是否生效
登录钉钉群聊，查看机器人发送的历史消息。确认每条消息的标题或第一行文本是否包含预期的项目标识。检查不同项目触发告警时，标识是否随之变化。若开启日志记录，核对发送请求的 body 内容与群内显示内容是否一致。
常见坑
1. 频率限制触发
多个项目共用 webhook 会累加调用次数。钉钉机器人对单个 webhook 有频率限制，公开资料中没有看到可靠的量化数据，但高频调用会导致接口返回限流错误，导致部分项目告警丢失。
2. 签名密钥泄露
共用 webhook 意味着共用加签 secret。若某个项目代码泄露，攻击者可伪造任意项目名义发送消息。建议仅在内网可信环境共用，核心系统建议独立机器人。
3. 消息格式错误
不同项目代码可能由不同人员维护，markdown 语法不一致可能导致消息渲染失败。建议提供统一的发送 SDK 或模板，强制规范消息结构。
常见问题
能否通过钉钉后台给 webhook 打标签来区分？
不能。钉钉机器人后台不支持为同一个 webhook URL 配置来源标签，区分逻辑必须在发送端实现。
共用 webhook 会影响消息到达率吗？
会。所有项目共享同一个机器人的发送配额，若某一项目发送过于频繁触发限流，其他项目的消息也会被拦截。
是否建议生产环境多个核心项目共用 webhook？
不建议。核心项目应独立创建机器人，避免相互干扰，便于独立管控权限和审计消息来源。
参考来源
- 钉钉开放平台 - 机器人消息发送接口文档，URL: https://open.dingtalk.com/document/robots
- 钉钉开放平台 - 自定义机器人接入指南，URL: https://open.dingtalk.com/document/robots/custom-robot-access