用华为云FunctionGraph重构我的自动化任务：停掉常驻云服务器后，我踩过的3个冷启动与依赖坑

做独立开发这两年，我手里跑着不少杂七杂八的定时任务：每天早晨定时抓取行业资讯推送到飞书、夜间自动备份数据库到对象存储、定期检查几个个人网站的证书过期时间等。过去我一直是在一台2核2G的轻量云服务器上跑cron加Python脚本。上个月服务器快到期，续费一看又要几百块，算下来这些脚本每天实际运行时间加起来不到20分钟，让一台机器24小时开着实在太浪费。于是我花了两个晚上，把所有任务全盘迁到了华为云的FunctionGraph（函数工作流）。这一趟折腾下来，服务器直接关机省钱，但也踩了几个只有自己动手才能遇到的坑，特意记录下来给想省钱的个人开发者参考。

一、把常驻脚本变成无状态函数
我的需求并不复杂，主要就是几个Python 3.9脚本，原本依赖requests、BeautifulSoup以及一些自建的消息推送逻辑。
华为云FunctionGraph每个月有免费的调用次数和执行时间额度，对于个人每天只跑几百次的定时任务来说，算下来基本等于零成本运行。
我最初的构想很简单：照着控制台新建几个事件函数，把Python代码贴进去，配置个Timer定时触发器就算搞定了。但实际跑起来才发现，Serverless的运行机制和自己的Linux虚拟机完全是两码事。

二、排查与避坑过程

第一个坑：第三方依赖打进代码包，冷启动直接超时
在自己的云服务器上，pip install一跑万事大吉。但在函数计算里，代码和第三方库都需要打成zip包上传。
我一开始把pandas和cryptography等比较重的库全打包了进去，压缩包直接飙到了几十兆。结果配置定时触发后，第一次执行经常莫名其妙报错超时。
后来发现，当函数从冷启动被唤醒时，平台需要从底层下载你的代码包并解压初始化。包体积太大直接把冷启动时间拉长到了四五秒，很容易卡死在默认超时的边缘。
解决办法是利用华为云的依赖包管理功能（Layer）。把通用的重型第三方库单独抽出来做成公共依赖层，函数代码本身只保留核心业务逻辑的几KB脚本；同时适当把单次调用的超时时间从默认的3秒放大到15秒，冷启动超时的现象立刻消失了。

第二个坑：把函数本地当作持久盘，文件悄悄丢失
我有一个脚本原本会把抓到的网页快照先临时写到本地磁盘做比对，第二天再拿来做差异分析。
迁到FunctionGraph后，脚本在本地测试正常，线上运行却发现偶发性比对失败，有时能读到昨天的文件，有时又提示文件不存在。
根本原因在于函数的无状态特性。函数的执行环境是由云平台动态拉起和销毁的，虽然提供了一块/tmp目录供临时读写，但只要实例一缩容释放，下一次触发可能被分配到了一个全新容器里，/tmp下的数据自然就没了。
最后我彻底摒弃了本地落盘的做法，把临时文件和差异比对全部改接到了华为云OBS对象存储里，利用OBS的Python SDK做流式读写，彻底解决了数据不一致的问题。

第三个坑：定时触发器的Cron时区差了8小时
这是最容易让人抓狂的一个隐形坑。我设置了一个定时任务，要求每天早晨8点整把整理好的新闻摘要推送到我的手机上，Cron表达式顺手写了0 0 8 * * ?。
结果第二天早晨8点手机毫无动静，直到下午4点突然叮咚响了一声推送。
翻了日志才反应过来：FunctionGraph的Timer定时触发器底层默认使用的是UTC时间（协调世界时），而我们平时习惯的是UTC+8北京时间。我写的早晨8点触发，在UTC标准下实际对应的是北京时间下午16点。
把Cron时间往前倒推8小时，修改为0 0 0 * * ?，或者在控制台明确选择时区后，定时推送才终于回到了每天清晨。

三、最终效果与成本核算
经过这一番改造，现在我所有的自动化脚本已经脱离云服务器稳定跑了大半个月：
原本那台专门挂后台任务的轻量服务器直接没有续费，每年稳稳省下一笔主机开销；
在FunctionGraph里，这些任务每天累计被触发上百次，单次执行耗时平均在一到两秒之间，产生的资源用量完全被每个月的免费额度覆盖，账单长期显示为0元；
更省心的是完全不需要再去管Linux系统补丁、Docker守护进程挂掉或者磁盘空间被日志撑爆的问题。

四、个人开发者总结
如果你的个人项目里也有很多低频、定时、非连续运行的后台任务，早点扔给Serverless绝对是性价比最高的选择。
迁移时记住三条经验：
依赖包尽量用平台提供的共享层，别把整个虚拟环境打包丢上去；
时刻记住函数实例随时会被销毁，千万不要依赖本地/tmp做跨次调用存储，有持久化需求老老实实对接对象存储；
设置定时器时多看一眼时区说明，别让本来早上的闹钟在下午响起来。