怎样让网站每天自动做一件事，而且不会重复执行或假报成功？
明确时区、授权、幂等和完成证据，将调度成功与业务成功分开记录。
本页目录
直接回答
定时器只负责在某个时间触发任务，业务是否完成还取决于接口、数据和外部服务。一种方案是外部调度器调用 Next.js API，并通过服务端密钥保护入口。整理建议：一项可靠任务还要说明重复触发怎么办、多个执行重叠怎么办、部分失败怎样补跑，以及什么证据才算完成。逐个处理邮件时，即使捕获了单个用户的发送失败，上层仍可能误报整体成功；应返回实际成功、失败与跳过情况，不能把“函数没有抛异常”当成全部完成。
适用场景
- 要定时发邮件、生成报告、清理数据或监控变化
- 任务显示成功，实际结果却缺失
- 手动补跑或平台重试导致重复消息与费用
一步一步做
定义任务与时间含义
写清处理哪段业务日期、何时触发、使用哪个时区、允许延迟多久。Cron 的分钟和小时只有结合时区才有意义。先确认下几次执行时间；涉及夏令时或跨日数据时，明确按照用户时区还是统一业务时区计算。
把业务做成可手动验证的入口
先在安全环境运行一次小范围任务，确认真实产出。接口读取服务端密钥并验证调用授权，密钥未配置时应明确失败，不继续业务。调度平台保存凭据的地方也要按其安全机制处理，避免出现在普通 URL 参数和日志里。
给一次业务建立稳定标识
补充方法：用任务类型、业务日期与目标对象确定一次应完成的工作，记录已处理状态，重复触发先判断是否已经完成。外部服务支持幂等标识时按其规则使用。不要把每次随机请求 ID 当作防重复依据，它无法识别同一业务重试。
处理并发、超时与部分失败
补充方法：避免两个运行同时领取同一项工作；数量增加后分批处理并保存进度。一个对象失败可以不阻止其他对象，但最终结果应准确汇总失败项。补跑只处理未完成部分，并核对外部调用是否已成功，减少重复副作用。
设置监控并演练失败
记录开始与结束时间、处理范围、产出位置和分类计数。区分未开始、进行中、成功、部分完成和失败。先测试无授权、重复触发、单项失败和中途停止，再启用正式计划；通知应指向需要行动的问题，而不只是持续发送成功消息。
验证调度器真的自动执行过一次
手动点击执行只证明入口可运行。按配置时区写出下三次预计触发时刻，等待一次真实计划触发，对照调度日志、服务端运行记录和最终产出。可以临时缩短周期做测试，但应只处理小范围测试对象，记录恢复正式周期的时间，避免每五分钟给全部用户发信。HTTP 200 只能证明该请求返回成功状态，任务若部分失败，自己的结果记录仍必须保留失败计数与补跑范围。
案例拆解
假设练习：每日通知邮件任务
假设计划每天早上按指定时区调用接口，再逐用户生成并发送通知。其中一封发送失败时，把错误记下来并继续其他用户是合理的，但整批结果应标明部分完成。若 8 个测试对象里 1 个失败，补跑应只处理该失败对象或核实未完成对象，而不是重新给全部对象发送。这个数字仅为演示，不是通用规模限制。
另一个假设情形是测试任务每五分钟运行、只处理两名测试用户。手动执行成功后，再看到一次由计划触发的运行，确认只新增两条预期产出、重试不重复；随后恢复每天一次，并记录新的三个执行时刻。若只看到计划已保存，验收结论应是“已配置，自动运行待验证”。
行动检查
可复制模板
定时任务合同
工作模板
任务及业务日期：［描述］
执行时间与时区：［时间、IANA 时区］
授权：［只填机制和变量名］
输入与输出：［范围、产出位置］
一次业务的稳定标识：［规则］
重试与并发：［如何避免重复］
状态：［成功／部分完成／失败及计数依据］
补跑：［只处理哪些未完成项］
验收：［正常、无授权、重复、单项失败、中断恢复］
首次自动运行验收单
计划名称／任务入口：
时区／表达式／下三次预计执行时间：
测试对象与限制：
手动运行证据：
自动触发时间／调度记录／服务端运行ID：
应处理数／成功／失败／跳过／真实产出位置：
重复与部分失败测试：
正式周期恢复时间与下次执行时刻：
结论：［已自动完成／部分完成／仅配置完成／未验证］
易错点
- 把调度平台的 HTTP 成功当成所有业务成功：响应必须反映实际结果。
- 捕获异常后始终返回 success：失败会从监控中消失。
- 重试整批邮件或生成任务：可能造成重复触达和重复收费。
相关指南
官方参考
- Resend：Send Email — 说明邮件发送 API 支持 Idempotency-Key；适用条件仍须按实际服务使用 资料核查记录日期：2026-10-18。