GitHub Actions 与 Vercel Cron 的执行边界

调度与执行分开判断

GitHub Actions 的定时事件启动工作流，作业在 runner 上运行脚本。Vercel Cron 则向项目生产部署的指定路径发送 HTTP GET，由对应函数处理。GitHub schedule、Vercel Cron 工作方式

Actions 可以直接执行数据处理，也可以只请求后端接口。后者只更换了触发来源：即使 runner 允许运行更久，被调用的 Vercel 函数仍受自身超时约束。要利用 runner 执行长任务，须把实际处理放在 runner，或调用其他支持长任务的执行系统。

GitHub 定时事件最短间隔为 5 分钟。工作流必须存在于默认分支；默认使用 UTC，也可指定 IANA timezone。高负载时可能延迟或丢弃排队任务，宜避开整点。公开仓库 60 天无活动会停用定时工作流。GitHub 调度限制

Vercel Cron 使用 UTC。Hobby 每个任务最多每天执行一次，时间精度为小时级；例如计划 01:00 的任务可能在 01:00—01:59 执行。Pro 和 Enterprise 支持最短每分钟一次、分钟级调度。这些频率不等于实时执行保证。Vercel 调度限制

GitHub-hosted runner 的单个 job 最长运行 6 小时；Vercel Cron 与普通 Functions 共用执行时长限制，实际还需核对项目配置。Actions 时长限制、Vercel Cron 时长

公开仓库使用标准 GitHub-hosted runner 的执行免费；私有仓库使用套餐内分钟数和存储额度，超额按规则计费。Vercel Cron 包含在各套餐中，但调用仍消耗 Functions 用量。Actions 计费、Vercel Cron 计费

Vercel Cron 不会在调用失败后自动重试，投递也可能漏发或重复；执行时间超过间隔时还可能重叠。Actions 的 schedule 同样不能保证每次准点触发。重要任务应保存进度、允许补跑，并让重复执行不产生重复业务结果；更换触发平台不能代替这些设计。Vercel 错误处理与幂等性

已有后端的短小维护任务，使用 Vercel Cron 通常更省配置；需要安装工具、生成文件、检查外部服务或运行较长批处理时，Actions 更灵活。可以让两者承担不同职责，避免同一写入任务同时被两套调度重复触发。

独立 runner 不能直接读取浏览器本地存储或其他服务实例的内存。周期请求也不能保证 Serverless 实例常驻，或归档所有实例的内存缓冲。任务应以明确的数据源和持久化结果为基础。