Webhook和定时任务有什么区别
Webhook 适合由外部事件主动通知系统，定时任务适合按时间节奏巡检、汇总和补偿。工程差别不在写法，而在触发来源、时效要求、失败处理和可追溯设计。
很多团队第一次做自动化时，会把 Webhook 和定时任务当成同一类东西：反正都是让系统自己干活，一个是“别人来叫我”，一个是“我自己每隔一段时间去看”。这个理解没有错，但还不够用。实际做项目时，选择错触发方式，问题不会马上暴露，而是会在延迟、重复执行、漏处理、账务对不齐、消息堆积时一起出现。
举个常见场景：用户在支付平台完成付款，你的网站需要开通会员；仓库里有新的 Pull Request，你希望自动通知团队；内容站每天凌晨要生成统计报表；每周一上午要把上周新增内容归档。这些动作都可以写成程序，但触发条件不一样。付款和 Pull Request 是外部系统里发生的事件，适合用 Webhook 通知你；日报、清理缓存、定期同步库存，是时间到了就要跑的任务，更接近定时任务。
这篇文章不讨论某一个框架的语法，而是从产品和工程视角拆开看：Webhook 和定时任务分别在解决什么问题，失败时会怎样，什么时候该二选一，什么时候应该组合使用。
Webhook：外部事件发生后，把消息推给你
Webhook 可以理解为一种“事件推送”机制。你在外部平台配置一个接收地址，例如 https://example.com/webhooks/payment。当平台里发生某类事件，比如支付成功、退款创建、代码提交、Issue 更新，平台就向你的地址发起 HTTP 请求，把事件数据放在请求体里。你的系统接到请求后，验证签名、解析 payload、记录事件、触发后续处理。
GitHub 文档把 Webhook 描述为订阅软件系统里的事件，然后在事件发生时把数据投递到你的服务器。Stripe 文档也采用类似设计：注册 HTTPS webhook endpoint 后，Stripe 会在账户中发生相关事件时推送实时事件数据，通常是 JSON payload。这里的重点不是“HTTP”三个字，而是触发权在事件源那里。你不是每分钟去问“有没有新事件”，而是让对方在事件发生时通知你。
这带来两个直接好处。第一，响应更及时。支付成功后几秒内开通权益，比每五分钟轮询一次支付状态更符合用户预期。第二，系统更省力。没有事件时，你不需要不断发请求；有事件时，外部平台把必要信息发来。
但 Webhook 也有代价。接收端必须暴露一个可访问的 HTTP 地址；必须验证来源，避免伪造请求；必须处理重复投递、乱序投递和失败重试；还要把接收请求和业务处理解耦。Stripe 文档明确建议 webhook endpoint 快速返回 2xx，再把复杂业务逻辑放到后续处理里，原因很朴素：对方是在等你的响应，如果你把重活都放在 HTTP 请求里做，容易超时，也会让对方判断投递失败并重试。
所以，Webhook 不是“收到就直接改数据库”的捷径。它更像一个事件入口：先验签，先入库，先返回，再由后台消费者继续处理。
定时任务：时间到了，由自己的系统主动执行
定时任务解决的是另一类问题：不等外部事件推送，而是按时间表主动运行。传统 Unix 世界里有 crontab，用固定格式表达“几点几分、每周几、每月哪天”执行命令。云平台和容器平台也提供类似能力，例如 Cloudflare Workers 的 Cron Triggers 可以把 cron 表达式映射到 Worker 的 scheduled() handler；Kubernetes CronJob 会按重复计划创建一次性 Job，适合备份、报表生成等固定周期动作。
定时任务要看的不只是“每隔多久跑一次”，而是它以时间为触发条件。时间到了，任务就尝试运行；有没有外部事件，不是它启动的前提。你可以每天凌晨同步昨天订单，也可以每十分钟检查一次是否有长时间未处理的消息，还可以每周清理过期临时文件。
定时任务的优势是可预测。你知道它会在什么时候跑，知道它大致会处理多少数据，也知道它适合做批量汇总、巡检、补偿和维护。它不依赖外部平台是否支持 Webhook，也不要求外部系统在事件发生时主动联系你。
但定时任务也有自己的坑。间隔太长，数据就不够新；间隔太短，就会形成无意义的轮询压力。任务运行时间超过调度间隔时，还会遇到并发问题：上一轮没跑完，下一轮又开始了。Kubernetes CronJob 文档专门提供了并发策略，例如允许并发、禁止并发、替换当前运行任务，并提醒开发者把任务设计成幂等，因为调度在某些情况下可能出现多跑或漏跑。这个提醒很重要：定时任务不是闹钟响一下就万事大吉，它还需要处理错过时间、重复运行、长任务堆积和时区差异。
它们最大的差别：谁决定“现在该做事”
Webhook 和定时任务最大的差别，是触发权在谁手里。
Webhook 的触发权在外部事件源。支付平台说“这笔订单支付成功了”，你的系统才接到通知；代码托管平台说“这个仓库有新的 pull request”，你的系统才收到 payload。你关心的是事件什么时候发生、事件是否合法、事件有没有重复、事件处理是否可追踪。
定时任务的触发权在自己的调度器。每天 03:00 生成报表，每十分钟同步一次数据，每小时检查一次失败队列。你关心的是时间表达式是否正确、任务会不会重叠、错过的任务是否补跑、运行结果是否有日志。
这个差别会直接影响系统设计。Webhook 是“外部变化驱动我”；定时任务是“我的时间表驱动我”。如果用户刚付款，系统必须尽快响应，那么把它做成每十分钟扫描一次订单，就会让用户等待。如果你每天只是统计昨天的访问量，强行让每一次页面访问都触发一个 Webhook 风格处理，又会把系统弄得过于敏感。
时效、成本和可用性的取舍
从时效看，Webhook 往往更接近实时。外部事件发生后，对方主动通知你，你可以很快进入处理链路。它适合支付状态、仓库事件、表单提交、工单更新、消息回调这类“事件一发生就希望系统知道”的场景。
定时任务的时效取决于调度间隔。如果你每小时跑一次，那么最坏情况下可能等接近一小时才处理。这个延迟不一定是坏事。报表、归档、备份、清理、周期同步，本来就不需要每秒响应。把这类工作集中在固定时间跑，还能降低系统常态负载，让运维更容易观察。
从成本看，Webhook 避免了大量空轮询，但它要求你维护稳定的公网入口、验签逻辑和事件消费队列。定时任务实现起来通常更直接，但如果用它频繁扫描外部 API，就可能制造很多无效请求，还容易碰到限流。
从可用性看，两者都不会天然可靠。Webhook 可能因为你的 endpoint 超时、证书配置错误、网络问题、签名验证失败而投递失败；定时任务可能因为调度器停摆、机器重启、时区配置错误、任务耗时过长而错过运行。工程上不能只问“它能不能触发”，还要问“触发失败之后有没有证据、有没有补偿、有没有防重”。
失败处理：Webhook 要防重复，定时任务要防堆积
Webhook 的失败处理通常围绕“投递”展开。外部平台会记录某次投递是否成功，常见判断依据是你的 endpoint 是否返回 2xx。Stripe 文档提到，直播模式下会对未成功投递的事件进行自动重试，并且事件不一定按生成顺序送达。这意味着接收端不应该假设“我只会收到一次”，也不应该假设“先发生的事件一定先到”。
因此，Webhook 接收端至少要有四个习惯。第一，验证签名或密钥，确认请求来源可信。第二，用事件 ID 做防重，收到重复事件时能识别出来。第三，把原始事件和处理状态记录下来，便于之后查账、补偿和审计留痕。第四，业务处理要幂等，例如“把订单状态设为已支付”通常比“余额加一次”更稳。
定时任务的失败处理则围绕“运行”展开。它要回答：上一轮没结束时下一轮怎么办？调度器停了一小时后，要不要补跑错过的任务？某次任务处理到一半失败，下一次从哪里继续？Kubernetes CronJob 的 startingDeadlineSeconds、concurrencyPolicy、timeZone 等配置，反映的就是这些问题：错过多久还算值得启动，是否允许重叠运行，用哪个时区解释调度计划。
对定时任务来说，最怕的是“看起来一直在跑，但结果已经不可信”。例如每五分钟同步一次库存，某次卡住后后续任务继续叠加，最后外部接口被打满，日志里却全是“任务已启动”。好的定时任务应该有游标、批次号、锁、超时、失败记录和告警，而不是只有一行 cron 表达式。
安全边界也不同
Webhook 是别人主动打到你的系统，所以安全重点在入口。你要限制请求方法，通常只接受 POST；要校验签名、时间戳或共享密钥；要保存 request id 或 delivery id；要避免把 webhook endpoint 当作普通公开 API 使用；还要让 endpoint 尽快返回，降低被慢请求拖垮的风险。
定时任务是你自己的系统主动执行，所以安全重点在执行权限。它可能拥有访问数据库、对象存储、第三方 API、后台管理接口的能力。你要确认任务用的账号权限是否过大，密钥是否能轮换，日志是否会泄漏敏感字段，失败重试是否会对外部服务造成压力。一个每天凌晨跑的脚本，如果权限过大，出错时破坏力可能比一个普通接口更强。
两者都需要审计留痕，只是留痕对象不同。Webhook 要记录“谁在什么时间把哪个事件投递给我，我如何处理”；定时任务要记录“哪个计划在什么时间启动，处理了哪些批次，结果如何”。
什么时候选 Webhook
当你的动作依赖外部系统里的事件，并且你希望尽快响应，优先考虑 Webhook。典型场景包括支付成功后开通权益、退款后更新订单、代码仓库事件通知、表单提交后进入 CRM、第三方平台审核状态回调、聊天机器人收到消息后触发处理。
选择 Webhook 前，要确认几个条件：外部平台是否支持相应事件；是否提供签名验证机制；是否有投递日志和重试策略；payload 里是否有足够的事件 ID、对象 ID 和时间信息；你的系统是否能提供稳定 HTTPS endpoint；业务处理是否能做防重和异步消费。
如果这些条件缺失，Webhook 仍然可以用，但不要把它当成唯一事实来源。比如对方可能只提供简单回调，没有完善的重试记录，那你就需要用定时任务做补偿扫描，定期核对“最近一段时间是否有漏处理事件”。
什么时候选定时任务
当任务本来就是周期性的，或者不需要由外部事件即时触发，定时任务更合适。典型场景包括每日统计报表、每小时同步数据、定期备份、清理过期文件、巡检失败队列、刷新缓存、批量生成内容摘要、对账和归档。
选择定时任务前，要把“时间表”写清楚：多久跑一次，按哪个时区解释，单次最长允许跑多久，上一轮没结束怎么办，错过执行是否补跑，失败后重试几次，输出结果在哪里看。对于会修改数据的任务，还要设计幂等键和游标，避免同一批数据被重复处理。
定时任务尤其适合做“补偿”。即使系统主要靠 Webhook 实时响应，也可以每天跑一次核对任务：查外部平台最近一天的订单、事件或文件列表，和本地记录比对，发现漏处理就补上。这样一来，Webhook 负责快，定时任务负责稳。
很多成熟系统会两者一起用
把 Webhook 和定时任务当成二选一，常常会让系统变脆。更稳的方式是组合使用。
例如支付系统可以这样设计：支付平台通过 Webhook 通知订单状态变化，接收端验签后写入事件表并快速返回 2xx；后台消费者根据事件 ID 幂等处理订单；每隔一段时间，定时任务从支付平台拉取最近订单状态，和本地订单做核对；如果发现本地缺事件或处理失败，就进入补偿队列；所有动作都有 request id、event id、批次号和处理状态。
这种设计看起来多了一层，但它把“快”和“稳”分开了。Webhook 让用户不必等下一轮扫描，定时任务让系统不怕某一次投递失败。对于内容系统、自动发布系统、素材处理系统也是一样：Webhook 可以接收外部平台事件，定时任务可以做巡检、归档、过期清理和失败补偿。
一个简单判断表
如果你还在犹豫，可以按下面几个问题判断。
第一，动作是不是由外部事件触发？如果是，先看 Webhook。第二，用户或业务是否要求接近实时？如果是，Webhook 的优先级更高。第三，平台是否支持可靠的事件投递、签名和日志？如果不支持，就要准备定时补偿。第四，任务是否原本就按天、按小时、按周执行？如果是，定时任务更自然。第五，任务是否可能长时间运行或处理大量数据？如果是，定时任务通常更容易分批和观察。第六，漏处理的代价是否很高？如果高，就不要只靠单一路径，要组合事件推送和周期核对。
落地清单：别只写触发器
不管选择哪一种，都不要只停在“写一个接口”或“加一行 cron”。可上线的自动化触发，至少要把下面这些事写进设计。
Webhook 侧：事件类型清单、签名验证、接收超时、快速返回、原始 payload 留存、事件 ID 防重、异步队列、处理状态、失败重试说明、手动重放入口。定时任务侧：cron 表达式、时区、最长运行时间、并发策略、游标或批次号、失败重试、错过执行策略、运行日志、告警、手动触发入口。
最后，用一句话收束：Webhook 适合“事情发生了，马上告诉我”；定时任务适合“时间到了，我去检查或处理”。成熟的系统不会迷信某一种触发方式，而是让事件推送承担时效，让周期任务承担核对和补偿，再用日志、幂等和审计留痕把两条路径接起来。
