【工具链】定时任务健康检查：调度任务的审计与兜底

实战应用：用在哪里

统一心跳调度器（合并定时器篇）收敛了调度入口，但任务本身的健康状态仍需审计：哪些任务长期失败、哪些任务周期被改过、哪些任务注册后从未成功执行。健康检查脚本定期审计调度器的任务清单与执行统计，是调度体系的运维入口。

审计数据：任务执行的三个计数

调度器为每个任务维护三个计数：执行次数、失败次数、最近一次耗时。审计脚本周期性导出快照：

function Scheduler.report()
    local report = {}
    for name, t in pairs(Scheduler.tasks) do
        report[#report + 1] = ("%-16s 执行:%d 失败:%d 耗时:%.2fms")
            :format(name, t.runCount, t.failCount, t.lastMs or 0)
    end
    table.sort(report)
    return report
end

失败计数非零的任务在报告里标红提示，连续失败的自动进入待修清单。执行次数长期为零的任务说明注册后从未到点，检查周期配置是否正确。

三类异常的处理预案

连续失败任务：先 pcall 隔离（已在调度器内），连续失败 3 次自动禁用并告警，防止坏任务拖垮整个心跳。耗时超标任务：lastMs 超过帧预算一半的任务标记为"应分帧改造"，进入优化清单（参考分帧实例化篇）。幽灵任务：对应功能已下线但任务仍注册的，从注册清单删除——幽灵任务是最常见的审计发现。

与发布流程的绑定

任务注册清单进版本库，每次热更的 diff 里能看到"新增了哪些周期任务、调整了哪些周期"。调度审计报告与发布 diff 交叉比对，新任务的引入时间、失败曲线一目了然。定时任务的数量会随功能增长持续膨胀，健康检查让膨胀始终在可见范围内——调度体系可维护性的关键就在这份审计报告。

报告的归档与推送

审计报告按日归档到 reports 目录，异常任务清单通过既有推送通道发给运维群。连续三日的报告对比能看出任务耗时与失败数的趋势，趋势恶化比单日异常更值得投入排查。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。