Webhook（网络钩子）是一种让用户定义的 HTTP 回调机制，它允许一个应用在特定事件发生时，自动向另一个应用发送实时数据或通知。
你可以把它想象成一种“订阅-推送”服务。与需要不断询问“有新消息吗？”的传统方式不同，Webhook 会在有新消息时主动通知你。
💡 核心思想：从“拉取”到“推送”
为了更好地理解 Webhook，我们用一个生活中的例子来对比：
- 传统方式 (轮询/Polling)：就像你想知道快递是否送达，需要每隔几分钟就跑到小区门口的快递柜去查看一下。这种方式非常耗费精力，而且大部分时间都是白跑一趟。在技术上，这对应着客户端不断向服务器发送 API 请求来查询数据是否有更新。
- Webhook 方式 (推送/Push)：就像你告诉快递员：“快递一到，就给我打电话。” 快递员（服务器）会在快递送达（事件触发）时，主动给你（客户端）打电话（发送 HTTP 请求）通知你。这种方式高效、实时，且只在真正有事情发生时才进行通信。
正因为这种“反向”的通信模式，Webhook 也常被称为 “反向 API” 或 “推送 API”。
🔄 Webhook 的工作流程
Webhook 的工作流程通常包含以下几个步骤：
- 事件发生：在源应用（如 GitHub、PayPal）中发生了一个预设的事件，例如有人提交了代码、创建了一个新的 Issue 或完成了一笔支付。
- 发送请求：源应用会立即向你预先配置好的 URL（即 Webhook 地址）发送一个 HTTP POST 请求。
- 携带数据：这个 POST 请求的“身体”（Body）里会包含关于该事件的详细信息，通常以 JSON 格式呈现。
- 接收并处理：你的服务器接收到这个请求后，解析其中的数据，并执行相应的操作，比如更新数据库、发送一条通知到 Slack 或触发一个自动化脚本。
🌐 常见应用场景
Webhook 被广泛应用于各种需要实时通知和系统集成的场景：
- 持续集成/持续部署 (CI/CD)：当开发者向 GitHub 仓库推送代码时，GitHub 通过 Webhook 通知 Jenkins 或 GitLab CI 服务器，自动触发代码构建和测试流程。
- 协作工具通知：当监控系统（如 Prometheus Alertmanager）检测到服务器故障时，通过 Webhook 向 Slack、钉钉或企业微信群发送告警消息。
- 支付集成：当用户在网站上完成支付后，支付网关（如 Stripe、PayPal）通过 Webhook 通知商家的服务器，服务器收到通知后更新订单状态为“已支付”。
- 自动化运维：当配置管理仓库（如 Git）中的基础设施代码发生变更时，通过 Webhook 触发自动化工具（如 Terraform）来更新云资源。
🛡️ 安全性
由于 Webhook 接收的是外部请求，安全性至关重要。最常见的保护方式是签名验证。
- 工作原理：发送方在发送请求时，会使用一个共享的密钥（Secret）对请求内容进行哈希计算，并将生成的签名放在 HTTP 请求头（如
X-Hub-Signature）中。 - 接收方验证：接收方收到请求后，使用同样的密钥和算法对请求内容进行哈希计算，然后将计算结果与请求头中的签名进行比对。如果两者一致，就证明请求确实来自可信的发送方，且内容在传输过程中未被篡改。