迅果本次上线定时调度。此前作业流的动作组合、并发档位与失败处理已经可以保存为预设，但什么时候着手跑照样要人点一下。这一版本把预设接到时间轴上：可以设定每天、每周或每月的执行时刻，也可以只跑一次；到点由本机调度器唤醒客户端执行，错过了在补跑窗口内自动补上。在 63 个工作室样本的 1,860 次定时触发中，准点触发率为 99.4%，补跑成功率为 98.7%，需要人工手动启动的次数下降 72%。
作业定在某个时刻，人就得守在那儿
批量作业里有很大一部分是「每天同一时间做同一件事」：早班前核验一遍账号状态，晚班后导出当天回执，月初把上个月的礼品卡台账再次对一遍。这些作业的动作和参数几乎不变，变的只有日期。
过去这类作业靠人记时间。我们在 63 个工作室样本里统计了固定时刻作业的分布：平均每天 3.8 次，其中 41% 落在 20:00 之后或 08:00 之前。手动启动的平均时间比计划晚 22 分钟；有 17% 的日子因为忘记启动而整天漏跑，漏跑之后要么临时补一份清单，要么把前一天的旧结果和新一天的数据混在一起处理。
漏跑带来的麻烦不只是少跑一次。批量作业通常按「当天清单」组织，漏跑意味着第二天要先判断哪些条目已经处理过、哪些还没有，判断流程本身又要花时间。定时调度的意义不是把按钮换成闹钟，而是把作业节奏固定下来，让结果按天对齐。
定时规则怎么设，执行窗口怎么定
定时规则挂在预设上，而不是挂在单个动作上。创建规则时先选一份预设，再选触发做法与时间。预设里的动作顺序、并发档位、失败处理与重跑策略会被完整继承，定时任务执行时不允许临时改动动作，需要调整就先改预设。这样做是为了避免无人值守时配置悄悄漂移，第二天看报表才发现口径变了。
| 规则类型 | 适用场景 | 主要参数 |
|---|---|---|
| 单次执行 | 活动节点、一次性补跑 | 日期、时刻、过期策略 |
| 每日 | 每日对账、账号状态巡检 | 一个或多个时刻、工作日或自然日 |
| 每周 | 周报汇总、周末批量整理 | 星期、时刻 |
| 每月 | 月度核对、账单归档 | 日期（月末按当月到到到到到最后一天）、时刻 |
| 固定间隔 | 高频巡检、阶段性任务 | 间隔小时或天数、起止日期 |
每条规则都带一个执行窗口，由「最早不早于」和「最晚不晚于」两个时间点组成。窗口的作用是给调度留出容错空间：本机在计划时刻处于睡眠、正在执行其他作业或暂时没有接通电源时，只要还在窗口内，调度器会在前提满足后补跑。超出窗口则按过期策略处理，可以挑选标记为跳过并留一条记录，也可以排队到下一个窗口再执行。
时间以本机时钟为准，规则里不额外存一套时区。系统时间被手动调整或跨时区出差时，调度器会先比对上次触发记录，再决定是否补跑，避免同一时刻被触发两次。补跑窗口缺省 6 小时，可以在 1 到 24 小时之间修改；同一个窗口内同一份作业只补跑一次，不重复执行。
本地唤醒、错过补跑与冲突避让分别管什么分别管什么分别管什么
调度器运行在本机，规则、预设与回执都存放在本地工作目录，不依赖云端下发任务。这一点与已经上线的本地处理策略一致：账号凭据照样只在本地加密存放，定时触发不会把凭据或清单内容带出设备。
本机睡眠时的处理分两种情况。接通电源时，客户端可以在计划时刻前唤醒系统，执行完成后恢复原来的睡眠状态；使用电池时不强制唤醒，避免为了跑批把电量耗掉，而是等系统下次唤醒后在窗口内补跑。这个开关可以按规则单独设置，也可以全局关闭自动唤醒，只保留补跑。
- 冲突避让：同一份作业上一轮还没结束时，可挑选排队等下一轮或直接跳过，不会两个实例另外读写同一份清单
- 同刻排序：多个规则落在同一时刻时按优先级依次启动，前一个进入执行后下一个再着手，避免并发档位叠加
- 手动优先：手动启动的任务优先占用档位，定时任务顺延到下一个窗口
- 资源门槛：仅在接通电源、磁盘剩余空间高于设定阈值时启动，前提不满足则等待并记录原因
- 调度回执：每次触发生成一条记录，含有计划时间、真实启动时间、触发做法（准点、补跑、手动）、花费时间与结果
把长作业挪到低峰时段是这次上线后被用得最多的做法。样本里有 29 个工作室把原来在白天执行的导出与核验作业改到 02:00 到 06:00 之间，夜间时段的平均处理吞吐比白天提升 33%。这个数字会随目标服务的响应情况变动，不构成对所有环境的承诺；如果目标服务在夜间本身有限流，提升幅度会明显收窄。
先试跑、再上线、然后盯着
定时任务在无人值守时执行，上线前建议按三步走。第一步，用 200 条真实样本试跑整份预设，确认动作顺序与输出列符合预期；第二步，让规则先跑一个完整周期，至少经历一次补跑，观察触发时间与真实启动时间的偏差；第三步再放大，把清单换成全量数据。
定时面板里能看到每条规则的下次触发时间、上次执行结果、连续成功次数与最近五次的花费时间曲线。连续失败达到 3 次时，规则会自动暂停并给出提示，避免在目标服务异常时反复重试。暂停后需要人工确认再恢复，恢复时会再次计算下一次触发时间，不会立刻补跑所有错过的周期。
执行结果与审计报表是打通的。报表可以按定时批次筛选，把一周内多个批次合并成总表，按批次与状态统计成功与失败条数；需要定位单条记录时，仍可追溯到时间戳与错误原因码。对于涉及金额或资格判定的作业，我们建议首周保留人工复核：定时调度保证的是按计划执行并如实留痕，不替代对结果的业务判断。
本页数据来自内部样本测试：63 个工作室、1,860 次定时触发、观察周期 4 周。准点触发率按「真实启动时间与计划时间偏差不超过 60 秒」统计，补跑成功率按「进入补跑窗口后最终完成」统计。真实环境中的表现会受电源状态、系统休眠策略、网络与目标服务响应影响，样本数字仅用于说明能力边界。
用户评论
建议先把补跑窗口设大一点，观察一周再收紧。窗口太小的时候，系统刚好在睡眠里就会直接过期。
夜间跑导出确实快，白天目标服务响应慢的时候，同样的量要多花一半时间。
定时任务不能临时改动作这一点一着手不太习惯，后来发现是好事，避免第二天看报表才发现口径被改过。
希望下次能按「每月第若干工作日」来设，账单核对经常要避开周末。
手动优先这个逻辑很实用。白天临时插一个任务进去，不会和定时的撞在一起。
连续失败三次自动暂停救了一次，目标服务维护那天没有反复重试把账号跑出异常。