工作原理
服务提供方产生事件（如 order.paid、user.created、build.finished），查找订阅该事件类型的端点，发送携带 JSON 负载和签名头的 HTTP POST。接收方验证签名、快速返回 2xx 确认，再异步处理。投递通常是至少一次，因此处理器必须幂等：保存事件 id 并跳过重复。顺序也很少得到保证，负载信息不足时应重新获取权威资源。
POST /hooks/orders HTTP/1.1
Content-Type: application/json
X-Signature: t=1750000000,v1=5f2c...
X-Event-Id: evt_8f21
{"type":"order.paid","data":{"order_id":"ord_123"}}何时使用与取舍
当消费者需要及时响应、轮询又会浪费资源时使用 Webhook：支付确认、CI 结果、聊天消息、库存变化。如果消费者位于同一信任边界且双方都由你控制，消息队列或事件流通常比出站 HTTP 更可靠。
Webhook 反转了控制权：你的端点成为公开攻击面，提供方的重试策略变成你的流量，处理过慢会触发重试并放大负载。提供方看不到你的系统内部，2xx 只表示收到，不表示处理成功。生产实现应加入签名密钥、重放窗口、死信处理和投递日志。
常见误解
秘密 URL 不是认证；URL 会泄漏，必须校验负载签名。重试也不等于最终处理成功，处理器静默丢弃失败时事件仍会丢失。负载只是事件快照，不是事实来源。相关概念：幂等性、重试预算、Outbox 模式。