用Trae写自动签到脚本，部署Serverless定时任务全复盘

出差一周回来，打开Trae发现每天签到断了三天，月底的兑换码活动恰好错过。那一刻我意识到，靠人肉去守一个每天固定时间刷新的活动，迟早还会再漏。于是就有了这个项目：用Trae写一个自动签到脚本，部署成Serverless定时任务，让它每天早上自己去签到，再把结果推到我手机上。

这篇不是“照着敲就能跑”的教程，而是这个项目从方案选型、脚本编码、Serverless部署，到线上踩坑的完整复盘。我会讲清楚每个选择背后的理由，并把核心代码、部署配置、以及运行几个月后的稳定性数据摊开。如果你也有每日签到、定时巡检、定时推送这类需求，正在纠结用什么方案，或者已经在用Serverless但总被定时触发器坑到，这篇应该能帮你省不少时间。

1. 方案选型：为什么最终落在 Serverless 定时任务上

1.1 摆在我面前的三条路

要做每天早上自动签到，候选方案其实很明确：云主机上的cron、GitHub Actions的schedule、以及Serverless平台的定时触发器。我把它们在表格里拉了一遍。

先说GitHub Actions为什么被我否掉。schedule事件本质上是“尽量执行”的，仓库如果长时间没有其他活动，任务被排队、被跳过的情况很常见。而且它的runner在海外，访问国内接口的稳定性真的看运气。我还特意把签到用的token放到了仓库Secrets里，虽然方便，但每次任务都在公共网络环境里执行，心里总觉得不踏实。

云主机这条路上，我家里确实有台小主机，但让它24小时挂着跑就是为了每天早上一个请求，先不说电费和带宽，光是出门在外家里断电断网一次，这个方案就废了。更别说还得维护系统、处理家里网络环境的端口和防火墙问题，投入产出比太低了。

1.2 为什么没碰 xxl-job、Spring Boot 这类企业级方案

做技术选型时很容易进入一个误区：看到什么热就用什么。搜索里提到xxl-job、SpringBoot定时任务、SpringCloud分布式定时任务，这些我都想过，但最后还是放弃了。

xxl-job这类中心化调度平台，适合企业中几十上百个定时任务需要统一管理、分片执行、可视化运维的场景。它本身需要部署调度中心、依赖数据库、还要维护执行器。我一个人一个签到脚本，引入它意味着要先维护一套基础设施，然后再为自己的简单需求写一堆配置，把简单的事情彻底做重了。

Spring Boot + @Scheduled 也一样。如果只是为了跑一个脚本，就得维护一个Java应用的构建、打包、部署链路，还要保证某个环境长期在线运行。对个人小任务来说，这等于“为了喝牛奶养了一头牛”。

Serverless为什么合适？因为它的模型是“你只提供一个函数，平台负责在触发时拉起它”。平时不存在、不占资源、不产生费用，到了时间点被唤醒，跑完就消失。用来承载每天一次的轻量签到任务，从资源消耗的角度来说几乎等于零。

1.3 选型结论与成本账

最终我选了阿里云函数计算FC，Python 3.9 runtime，region放在杭州，配置一个每天触发的定时触发器。

理由有三条：

• 访问国内接口延迟低，不用绕路海外。
• 支持定时触发器，原生就能配置cron表达式，不需要额外搭调度服务。
• 免费额度对这种每天调用一次的任务来说完全够用，就算哪个配置错了也不至于产生明显账单。

成本账大概算一下：一个月触发30次，每次执行时间几秒，内存128MB，这个量级放在任何云厂商的免费额度里都是毛毛雨。相比自己养一台机器，省下的电费和精力都是实打实的。

2. 用 Trae 写签到脚本：从抓包到能跑通的核心代码

2.1 先想清楚接口调用链路再动手

签到本质就是一个HTTP请求：带着登录凭证去请求签到接口，后端返回是否成功。关键是要把下面几件事搞清楚，否则代码写出来也是空中楼阁。

• 请求方法、URL、headers、请求体格式。
• 登录态的承载方式：Cookie还是Bearer Token。
• 成功返回的结构：怎么判断“签到成功”“重复签到”“接口异常”。
• 同样的请求如果被重复触发，会不会出问题（幂等性）。

我是用浏览器开发者工具抓包，找出签到请求的完整信息，然后把请求信息丢给Trae，让它帮我把requests代码骨架写出来。这种模式比手写快很多，特别是headers里一堆字段顺序、Cookie字段名容易眼花，让代码编辑器先出一版，再手工校对，效率高不少。

2.2 脚本骨架与核心代码

我最终的入口函数按FC的Python runtime规范写成handler形式，整体逻辑非常直白：读取环境变