Webhook 事件驱动自动化入门：跨系统联动

结论先行：Webhook 的本质是"对方出事主动通知你"——支付成功、表单提交、工单创建时，对方系统主动向你的地址发一个请求，你据此触发后续流程。把它做稳只需要三件事：签名校验防伪造、重试机制防丢失、幂等设计防重复。掌握这三点，跨系统联动的可靠性可以达到生产级。

做自动化的团队常遇到这种需求：支付成功后自动开通会员，表单提交后自动发通知，工单创建后自动派单。如果每隔几秒去问一次"好了吗"，既浪费资源又有延迟。Webhook（网络钩子）就是为了解决这个问题：把"你去问"变成"它来说"。

一、三步链路：事件源→回调→处理流

用快递类比理解事件驱动：轮询（Polling）是你每小时打电话问快递"到哪了"；Webhook 是快递员主动打电话通知你"到了，来取件"。

对比项	轮询	Webhook 事件驱动
实时性	取决于轮询间隔，分钟级延迟	秒级
资源消耗	大量无效请求	事件发生才请求
实现成本	需自己维护定时器	配置回调地址即可
可靠性前提	不丢轮询周期	需处理重试与幂等

完整链路三步：第一步，事件源（支付平台、表单系统）发生业务事件；第二步，事件源向你预先登记的回调地址发起 HTTP 请求，携带事件数据；第三步，你的处理流接收数据，执行后续动作。

二、签名校验：先证明"真是它发的"

回调地址暴露在公网上，任何人都能伪造请求。标准做法是签名校验：事件源用密钥对请求内容计算签名放在请求头里，你用同样的密钥验证。

// Node.js 验签示例：HMAC-SHA256
const crypto = require('crypto');
const expected = crypto
  .createHmac('sha256', SECRET_KEY)   // 用约定的密钥
  .update(rawBody)                    // 对原始请求体计算签名
  .digest('hex');
if (expected !== req.headers['x-signature']) {
  return res.status(401).end();       // 验签失败直接拒绝
}

同时记得校验时间戳，超过 5 分钟的请求视为过期，防止重放攻击。

三、重试与幂等：不丢也不重

两个事实决定了你的设计：一是网络抖动时你的服务必须快速返回 200，处理不过来就先落库再异步处理；二是多数平台在你未及时响应时会自动重试，间隔 5 秒、1 分钟、10 分钟不等，最多重试数次。于是同一事件可能到达两次以上——幂等（Idempotency）设计就是解决"重复到达不重复处理"。

四个要点：1）用事件唯一 ID 建去重表，收到已处理过的事件直接返回成功；2）处理逻辑写成"按结果设置状态"而不是"叠加执行"，重复执行结果不变；3）处理失败返回 5xx，让对方重试，而不是吞掉错误；4）去重记录设过期时间，避免表无限膨胀。

四、在低代码平台里落地

以猫拽低代码（CatPull）为例，Webhook 事件可以直接作为工作流的触发入口：回调进来后进入节点式编排，用条件分支按事件类型分流，用变量赋值提取关键字段，再用 HTTP 请求节点或云函数代码节点执行开通会员、发送通知等动作。全程可视化配置，验证签名和处理幂等都可以在云函数节点里用几行代码完成。

典型的联动场景：支付成功 → 更新订单状态 → 开通会员 → 发送短信；表单提交 → 内容审核 → 通过后入库并通知负责人。原来需要三四个系统人工衔接的环节，一条工作流全部接管。

FAQs

Q1：Webhook 没收到怎么办？

A：三步排查：确认回调地址公网可达且证书有效；查事件源平台的推送日志，看对方是否已投递、返回码是什么；对方显示投递成功而你没收到，检查网关与防火墙是否拦截了 POST 请求。关键业务建议每天跑一次对账任务兜底。

Q2：Webhook 和 API 有什么区别？

A：API 是你主动调用对方（拉模式），Webhook 是对方主动调用你（推模式）。同一个系统常常两者都有：用 API 拉取历史数据，用 Webhook 接收实时变化，配合使用覆盖完整场景。

Q3：回调处理耗时太长会怎样？

A：多数平台等待 3~10 秒就判定失败并重试，导致重复推送。正确做法是收到请求后立即校验、落库并返回 200，把耗时逻辑放进异步工作流处理，靠幂等设计保证不重复生效。

猫拽智库

Webhook 事件驱动自动化入门：跨系统联动

一、三步链路：事件源→回调→处理流

二、签名校验：先证明"真是它发的"

三、重试与幂等：不丢也不重

四、在低代码平台里落地