定时任务别再靠 cron 加裸脚本：用 FunctionGraph 做一次带重试的每日提醒

很多个人项目和小型团队的第一版定时任务，都是服务器上的一条 cron 加一个裸脚本：每天早上八点跑一次，拉取数据、拼一段提醒文案、调用接口发出去。刚开始它确实够用，跑上几个月之后，问题会一个接一个出现：机器重启后 cron 没恢复，脚本中途崩溃没有任何人知道，网络抖动导致提醒漏发一次，第二天又因为没有去重而重复发了一次。定时任务最怕的不是写不出来，而是失败时悄无声息。

把这类任务搬到华为云 FunctionGraph 上，思路可以换一下：不要再把“按时跑”和“业务逻辑”绑在同一台机器上。FunctionGraph 的定时触发器负责准时唤醒函数，函数本身只做一件小事——生成当天的提醒内容并发送。触发器用 cron 表达式配置，比如工作日早上八点执行一次，函数运行完就释放资源，不需要长期维护一台服务器，也不用担心机器重启把定时任务一起带走。

一个能放心用的每日提醒，至少要处理三件事。第一是幂等。提醒内容按日期生成，函数入口先算出当天的任务键，例如 reminder-2026-11-09，再检查这把键是否已经处理过，已经处理过就直接返回，不再重复发送。这样即使触发器因为重试多跑了一次，用户也不会收到两条一样的提醒。第二是重试。发送接口失败时不要立刻放弃，第一次隔三十秒重试，第二次隔两分钟，第三次隔十分钟，三次都失败再记为失败。指数退避比连续猛刷接口更友好，也更容易等到网络恢复。第三是可观测。每次执行都记录开始时间、任务键、发送结果和失败原因，失败时再发一条告警。没有记录的定时任务，等于没有定时任务。

函数内部的流程可以写得很直白。先做时间校验，确认今天是否需要提醒；再组装提醒内容，内容里只放当天真正需要的信息，不要把全量数据都塞进去；然后调用发送接口，成功就把任务键标记为已完成，失败就按退避策略重试。把发送逻辑和内容生成分开，之后想换提醒渠道、改文案或者加一个周末不提醒的开关，都只需要改一小处。配置也不要写死在代码里，提醒时间、接收方和重试次数都放进环境变量，换环境时改配置即可。

上线前建议先做三组验证。第一组用手动触发跑一次，看内容和发送结果是否正确；第二组故意把发送接口地址改错一次，看重试和告警是否按预期工作；第三组连续模拟两次触发，看幂等逻辑是否真的拦住了重复发送。这三组验证花不了多少时间，却能覆盖定时任务最常见的翻车场景。平时也可以定期翻一下执行记录，重点关注失败次数突然变多的那几天，往往是接口或者上游数据先出了问题。

成本方面，这类低频任务很适合函数计算。每天只跑一次，执行时间通常在几秒以内，按量计费的开销很低，省下的是服务器的维护成本和半夜起来排查的精力。对于还在验证想法的小项目，先把任务跑稳定，再考虑要不要把它做成更复杂的调度系统，是更划算的顺序。

总结一下：定时任务的难点不在触发，而在失败之后怎么办。把触发交给 FunctionGraph 的定时触发器，把幂等、重试和记录写进函数，再用三组验证把常见故障先演练一遍，一个每天八点准时提醒的小服务，就可以长期稳定地跑下去了。