FunctionGraph 定时触发器实操：每天定时跑任务，不用守着服务器

之前做图片压缩和水印的实验时，都是手动在控制台点"执行"来跑函数。后来有个每天定时清理临时文件的需求，总不能每天守着点一次，于是试了 FunctionGraph 的定时触发器：配一次，到点自动跑，实测下来比挂一台 ECS 跑 cron 省事，也更便宜。

一、先有个能跑的函数

定时触发器本身不产生逻辑，它只是到点调用你已有的函数。拿我之前做过的图片压缩函数举例：函数接收事件、从 OBS 读图、压缩后写回，代码本身不用为定时做什么改动。只要函数在控制台能手动执行成功，就可以挂定时。

新建函数时注意两点：一是运行环境选你代码真正用的（我用的是 Python3.9）；二是给函数配好访问 OBS 需要的权限，定时触发时没有人在旁边点授权，权限缺了就是静默失败，日志里才会看到报错。

二、创建定时触发器

1. 进 FunctionGraph 控制台，找到目标函数，点「触发器」→「创建触发器」。
2. 触发器类型选「定时触发器 CTS」（控制台里也叫 Timer），名字随便起一个能认出来的，比如 daily-cleanup。
3. 触发规则二选一：固定频率（比如每 1 天）或 Cron 表达式。每天凌晨跑一次，Cron 写 0 0 16 * * ?——注意这里是重点，往下看。
4. 事件内容可以留默认的 {}，函数收到的就是一个空事件；如果你的函数靠事件里的参数区分任务，在这里把参数写进去。

创建完触发器是启用状态，不用再点别的，到点就会触发。

三、最容易踩的坑：Cron 用的是 UTC 时间

这是我第一次配定时踩到的坑：我想让任务在北京时间每天凌晨 0 点跑，Cron 写了 0 0 0 * * ?，结果它在北京时间早上 8 点才执行。FunctionGraph 的定时触发器按 UTC 时间解析 Cron，北京时间要减 8 小时换算：北京时间 0 点对应 UTC 前一天 16 点，所以 Cron 应该是 0 0 16 * * ?。

换算公式很简单：UTC 小时 = 北京时间小时 - 8（不够减就往前一天借）。配完之后别急着等第二天验证，触发器列表里能看到下次触发时间，对一下是不是你想要的北京时间。

四、验证它真的跑了

定时任务最怕"以为跑了其实没跑"，验证分三步：

1. 看触发记录：函数详情页的触发器列表里有上次触发时间，时间对上说明触发器工作了。
2. 看函数日志：进函数的「日志」页，搜触发时间点附近的记录，有执行日志说明函数真的跑了；如果只有触发记录没有日志，多半是函数内部报错退出了。
3. 看结果：比如我的清理任务，跑完后去 OBS 桶里确认临时文件确实少了。只看日志不看结果，等于只验证了一半。

第一次配建议先把频率设成每 5 分钟跑一次，验证通过后再改回每天一次，省得等一天才发现配错了。

五、费用：免费额度基本够用

FunctionGraph 按调用次数和执行时长计费，每月有免费额度：调用次数和 GB-秒资源使用量各有一档免费量。每天跑一次的轻量定时任务，一个月 30 次调用，基本落在免费额度里，不会产生账单。我的图片压缩函数一个月跑下来，账单上只多了几分钱。

但要注意：如果函数里调用了按量计费的服务（比如我之前实验里调的 MAAS 模型接口），那部分费用是另外算的，跟定时触发器本身无关，账单要分开看。

六、几个实操提醒

• 定时触发器创建后默认启用，不想跑的时候在触发器列表里禁用，别直接删函数，删了触发器也跟着没了。
• 函数超时时间默认 3 秒（部分版本默认更短），定时任务如果处理量大，先在函数配置里把超时调大，不然跑一半被掐断，日志里只剩超时报错。
• 一个函数可以挂多个触发器，比如每天凌晨跑全量清理、每小时跑一次增量检查，分开配、名字写清楚。
• 调试期间触发器先禁用，改完代码手动执行验证通过后再启用，避免调试代码被定时触发跑到线上数据。

总结：定时触发器就是给函数加了个闹钟，配一次就不用管。记住 Cron 按 UTC 解析、配完先高频验证、看日志更要看结果，每天跑一次的轻任务基本不花钱。