通用方法 · 熟练
别问几点跑，问什么事发生时跑
「定点跑」是你猜时间，「事件跑」是事来找你
定时任务最容易失效的地方不是写错步骤，是时间点挑错了 —— 数据还没更新就跑了，或者在两次轮询之间发生的事被整段跳过。事件触发把判据从「几点」换成「什么事发生时」：邮件到了就跑分诊、频道有新动静就跑汇总、有人提交代码就跑检查。但它不是白拿的：换成事件触发之后，有三件原来不用管的事必须写清 —— 同一件事被投两次怎么办、事件没来怎么办、被触发的东西有没有权限去读那件事。这一页把「什么时候该换成事件」和「换过去要先写清哪三件事」分开讲，末尾附一条通用判据：有事件源就走事件、没有就老实定时 —— ⛔ 别为了「先进」硬改。
方法 · 一图看懂
1
先问「这件事有没有事件源」 — 有事件的地方（邮件 / 团队消息 / 代码托管 / 表单提交 / 支付回调）才谈得上事件触发；只有「时间到了」这一种触发条件的活（月度汇总、季度归档），老实留定时 —— 强行改只会多一层没人维护的订阅
2
把「我按点去看」换成「它来找我」 — 定点轮询的成本不在那一次执行，在于你没去看的那几次也在花时间与额度；事件触发的收益是「空跑归零」，代价是你必须给「事件」下一个可判定的定义（什么样的邮件算分诊对象？谁提交的代码算数？）
3
换过去先写清三件事 — ① 去重：同一事件可能被投递两次（重试 / 多路订阅）⇒ 要先定「这条已经处理过」的判据 ② 漏事件：事件通道断的时候，那一段静默丢失，得留一条「多久没收到事件就该报警」的兜底 ③ 权限：触发方与被触发方的权限是两套 —— 能读那封邮件的是连接器，不是那个任务
4
给「事件太密」留一条闸 — 一次风暴（批量提交 / 群发邮件）会把所有监听同一事件的任务同时点着；先定一条节流规则（同一来源 N 分钟内只跑一次），比出了事再加便宜得多
原理 · 为什么有效
事件触发之所以更省，是因为它把「判断有没有新东西」这件事从你这边挪到了通道那边。定点轮询的隐含假设是「我猜的时间点就是变化发生的时间点」，而事件触发的假设是「变化发生时有人会告诉我」 —— 前者要靠猜，后者只要有源就能成立。真正容易出错的地方在两者的失败形态不同：轮询失败是「空跑一次」，看得见、没后果；事件失败是「那件事根本没被通知到」，安静得多，往往过很久才发现。所以换过去不是把 cron 删掉，而是把「准时」这条保证换成了「不漏」这条保证 —— 后者需要你自己补上兜底。
适用场景
适用：有明确事件源的重复工作（收件箱分诊 · 频道与议题跟踪 · 代码提交后的检查 · 表单/订单到达后的处理）· 现在按小时或按天轮询、但大部分轮次都是空跑的定时任务 · 已经能稳定连上那套系统的人。
⛔ 不适用：只有「时间」这一种触发条件的活（月末汇总 / 季度归档 / 每周回顾）—— 那些没有事件源，改成事件触发只是把 cron 换了个名字。
⚠️ 前提：愿意先花十分钟把「什么样的事件才算数」写成一句可判定的话。
自测 · 5 问
我说得出这件事的事件源是什么（哪个系统的什么动作），而不是「大概每天有变化」
我写下了「什么算一次事件」的判定句 —— 拿三条真实样本对过，它都能判对
我定了去重判据（同一事件被投两次时，靠什么认出「这条处理过」）
我留了漏事件的兜底（多久没收到事件就该报警，而不是等你想起来）
我确认过触发方有权限读那件事（连接器的权限 ≠ 任务的权限，两套要分开核）
怎么上手 · 验证步骤
第一次别改整套。只挑一条「现在按小时跑、但十次里有九次是空跑」的任务，把它换成事件触发：先写下事件源与判定句 → 再写去重判据 → 最后加上「多久没收到事件就提醒我」。跑一周，看两件事：① 空跑的次数是不是归零了 ② 有没有哪次该跑却完全没动静。第二件比第一件重要 —— 它一旦出现，说明你要么判定句写窄了，要么事件通道本身不可靠，回去补兜底再谈收益。
自检动作：把这条任务近一周的「实际触发次数」与「你在通道里能数到的真实事件数」并排写下来。两个数应当对得上；如果实际触发显著少于真实事件，说明漏了；如果显著多，说明没有去重。写得出这两个数，这次改造才算验收过。