一句话：Webhook 是一种“你留个地址，事情发生时我来通知你”的机制——本质上是由事件触发的一次 HTTP 请求（通常是 POST）。
为什么不用轮询
假设你在等一个耗时十分钟的 AI 训练任务。轮询（polling）的做法是：每隔三秒发一次请求问“跑完了吗”。十分钟就是两百次请求，其中一百九十九次得到的回答是“还没”。这既浪费你的带宽，也浪费对方服务器的计算和配额，还要额外承受等待间隔带来的延迟——真跑完了，最长也要再等三秒才知道。
Webhook 把方向倒过来：任务一开始，你就把一个回调地址（callback URL，俗称“钩子”）交给对方。任务真正结束的那一刻，对方主动向这个地址发一个请求，把结果放在请求体里。你只被叫一次，而且几乎是实时。
生活里的比方：轮询是每三秒给快递站打个电话问“我的件到了吗”；Webhook 是留个手机号，快递到了给你发一条短信。
| 轮询 Polling | Webhook | |
|---|---|---|
| 谁发起 | 你反复去问 | 对方在事件发生时推给你 |
| 实时性 | 取决于你设的间隔 | 事件驱动的即时通知 |
| 资源开销 | 大量空转请求，随等待时长增长 | 只在真有事件时产生请求 |
| 前提条件 | 你能主动发请求即可 | 你需要一个对方能访问到的地址 |
和相邻概念的区别
API 是“你主动去问”，Webhook 是“对方主动告诉你”，两者常常配合使用：你调 API 创建任务，Webhook 把结果送回来。WebSocket 是双方维持一条长连接、随时互发消息；Webhook 是一次性、单向的 HTTP 通知，发完即结束，不需要维持连接。
工程上要注意什么
收到通知不等于事情就办完了。生产系统通常做四件事：验证签名（否则任何人都能伪造通知来打你的接口）、先快速返回 2xx 再异步处理（避免对方判定超时而重试）、保证幂等（同一事件可能被投递多次，用事件 ID 去重）、以及准备兜底对账（通知可能丢失，定期拉一次全量数据核对）。
对从业者的意义
AI 服务里有大量“长跑”任务：模型微调、批量推理、视频生成、Agent 的多步执行。把“完成通知”交给 Webhook，比让前端或客户端自己反复刷新要省得多，也更容易做成可靠的后台流程。对普通职场人来说，在后台里看到“回调地址”“通知 URL”这一栏时，可以把它理解成填一个“快递收件方式”，而不是要求你一直盯着页面刷新。
各家平台的事件字段、签名算法和重试策略并不相同，具体以官方文档为准。