1. 定时任务在 FastapiAdmin 中的定位与技术选型做过后台管理系统的人都知道单纯把 CRUD 做完只是第一步真正让系统活起来的往往是那些自动执行的任务每天凌晨同步一次数据、每周定时清理过期日志、每个月生成一份统计报表。FastapiAdmin 作为基于 FastAPI 的轻量级后台框架自然绕不开定时任务这个刚需功能。但真正动手去实现的时候很多人会卡在几个关键问题上任务是怎么被调度的数据库里的任务配置和执行器之间是怎么关联的新建一个任务时要填的那些参数到底是什么意思这篇内容专门把这些事情讲透。1.1 为什么需要定时任务以常见的数据同步场景为例——比如定时从第三方接口拉取数据写入本地库。这类操作有几个共同特征执行时间固定比如凌晨 2 点、执行频率可控每 5 分钟一次或每天一次、执行结果需要被追踪成功还是失败、耗时多久。没有定时任务的时候这些工作要么靠人工定时去点按钮要么写个死循环在某个进程里长期挂着前者浪费时间后者浪费资源且极不稳定。FastapiAdmin 内置的定时任务模块就是把这块能力标准化在管理后台新建一条任务记录填好执行时间、执行间隔、要运行的函数路径调度器自动完成后续的触发和调度。对使用方来说相当于把什么时候做什么事这件事从代码里抽离出来变成了数据库里的一条配置。1.2 为什么选择 APScheduler 作为核心调度引擎FastapiAdmin 在定时任务这块并没有重复造轮子底层核心是 APScheduler也就是 Python 生态里最成熟的第三方调度库。选择它而不是自己写线程睡眠循环原因主要有三个。第一个原因是可靠的时间计算。APScheduler 对 cron 表达式和 interval 间隔的支持非常成熟时区、夏令时、闰年这些边缘情况都已经处理过自己从零实现很容易在这些细节上翻车。第二个原因是任务的持久化能力。APScheduler 提供了多种 Job Store可以把任务配置存到内存、SQLite、MySQL 等介质中。这意味着后台管理界面里看到的那张任务列表本质上就是一张与 Job Store 对应的数据库表。服务重启后任务配置还在不需要重新录入。第三个原因是执行器的多样性。APScheduler 支持线程池和进程池两种执行器可以根据任务类型选择不同的运行方式——CPU 密集型任务用进程池IO 密集型任务用线程池这种灵活性是自制方案很难达到的。2. 调度器核心原理拆解四大组件如何协同工作要理解 FastapiAdmin 定时任务的实现原理绕不开 APScheduler 的四大核心组件触发器Trigger、任务存储Job Store、执行器Executor和调度器Scheduler。这四个组件各司其职配合起来才能完成到了时间就执行指定函数这件事。2.1 触发器Trigger三种触发模式的适用场景触发器解决的核心问题是什么时候执行、执行几次。APScheduler 提供三种内置触发器FastapiAdmin 在新建任务时暴露给用户选择的也正是这三种。date 触发器是最简单的一种指定一个具体时间点到点执行一次。适合明天凌晨 3 点执行一次数据库备份这种一次性任务。它有三个参数run_date运行日期、timezone时区、如果不指定 end_date 则只执行一次。interval 触发器是固定间隔执行比如每 30 分钟、每 2 小时。它的核心参数是 start_date开始时间、end_date结束时间、以及具体的间隔值。这里有一个很常见的坑interval 的间隔是从 start_date 开始计算的如果你把 start_date 设置为 10:00间隔 30 分钟那么任务会在 10:00、10:30、11:00 依次触发而不是每次间隔 30 分钟从 0 点开始对齐。如果你希望对齐到整点或整半点需要在 cron 触发器里配置分钟位。cron 触发器是最强大、也最容易出错的。它模仿 Linux 的 crontab 语法支持精确到秒、分、时、日、月、周等字段的表达式配置。例如每天早上 8 点执行任务cron 表达式是0 0 8 * * *对应秒、分、时、日、月、周。cron 触发器的灵活性在于它可以表达相当复杂的调度策略比如每月最后一个工作日 18:30 执行但表达式的可读性较差建议在管理后台界面上用表单让用户选择时分秒然后自动拼装 cron 表达式避免用户手写导致格式错误。2.2 任务存储Job Store任务数据放在哪里任务存储决定了任务配置的持久化方式。APScheduler 默认提供四种 Job StoreFastapiAdmin 中通常用到其中两种。MemoryJobStore是纯内存存储任务配置只存在当前进程的 RAM 中。优点是速度极快、无需额外配置缺点是进程重启后任务全部丢失。适合开发调试或任务配置不敏感的场景。SQLAlchemyJobStore是基于 SQLAlchemy ORM 的数据库存储任务数据会序列化后存入数据库表在 FastapiAdmin 中通常对应的就是任务管理表。这种方式的优点在于任务配置与后台管理数据天然打通管理界面里的增删改查直接映射到 Job Store 中任务的更新操作服务重启后任务能自动恢复注册。缺点是每次调度器启动时都需要先把任务从数据库读取出来注册到调度器中任务数量较多时启动耗时会有所增加。要特别留意的是Job Store 存储的 job 默认是以 pickle 序列化方式保存的如果你在任务函数里传递了不能被 pickle 序列化的对象如 lambda 函数、数据库连接等保存时会直接报错。这一点在设计任务参数时要提前规避。2.3 执行器Executor任务真正跑在哪里执行器决定任务被触发后以什么方式运行。默认的 ThreadPoolExecutor线程池执行器适合大多数 IO 密集型的场景比如网络请求、数据库读写。默认线程池大小在 APScheduler 中是 10也就是说同时最多跑 10 个任务任务超出部分会进入等待队列。另一个常配置的工具是 ProcessPoolExecutor进程池执行器适用 CPU 密集型任务比如大规模计算、图像处理。进程池执行器和线程池执行器的一个重要差异在于任务函数的返回值无法直接传回调度器也就是说你无法在 run 方法中拿到 process 任务的返回值。如果你的任务逻辑需要依赖上次执行的结果就必须自己将执行状态写到数据库或消息队列中。FastapiAdmin 在调度器初始化时通常会同时注册线程池执行器默认任务执行使用和进程池执行器可选给 CPU 密集型的同步任务用。新建任务时可以通过字段指定使用哪种执行器。2.4 调度器Scheduler把一切串起来的主控调度器是 APScheduler 的中央协调者负责将触发器、任务存储、执行器整合起来。FastapiAdmin 中通常使用的是 BackgroundScheduler。BG Scheduler 初始化时主要做三件事加载 Job Store、加载 Executor、创建调度线程。创建调度器实例后需要调用start()才能开始工作主线程不会被阻塞这也是它叫 Background 的原因。在 FastAPI 应用中调度器实例应当作为一个全局单例在 FastAPI 的 startup 事件lifespan中初始化并启动在 shutdown 事件中关闭避免多次初始化造成任务重复注册。调度器内部的运行逻辑大致是这样的调度线程会在每个调度循环中遍历所有已注册的任务检查当前时间是否已经到达任务设定的下一次触发时间如果到达则提交给对应的执行器运行。任务运行完毕后调度器根据触发器计算下一次触发时间并更新任务状态。每轮循环之间有微小的间隔默认 0.1 秒左右这也解释了为什么定时任务的实际触发时间存在毫秒级误差。3. FastapiAdmin 集成定时任务的架构设计与初始化流程理解了四大组件后下面要看 FastapiAdmin 是怎么把它们和后台管理界面结合在一起的。3.1 初始化顺序与生命周期管理在 FastapiAdmin 项目中定时任务的初始化不仅仅是 new 一个调度器对象那么简单。因为任务配置要从数据库读取对应 SQLAlchemyJobStore、要支持在后台界面进行增删改查对应 CRUD 路由、要连通任务运行日志对应日志表所以初始化顺序相当有讲究。标准的流程是创建 SQLAlchemy 数据库引擎确保任务存储表存在如果不存在则自动建表。在 FastAPI 的 lifespan 中或在 startup 事件中实例化 BackgroundScheduler添加 SQLAlchemyJobStore 作为任务存储。调用scheduler.start()启动调度器这时调度器会尝试从 Job Store 数据库中读取已有任务并注册到调度器中。把调度器实例绑定到 FastapiAdmin 的应用状态app.state.scheduler方便后续路由中调用。这里有一个实践中的细节FastapiAdmin 常把调度器实例放在一个单独模块中比如extensions.py避免循环导入的问题。同时在 lifespan 中要确保 scheduler.shutdown() 被调用否则服务在退出时可能会出现线程泄漏告警。3.2 任务模型设计与数据库持久化FastapiAdmin 的任务管理表通常包含的核心字段有任务名称name、触发器类型trigger_type、cron 表达式cron_expr、间隔秒数interval_seconds、执行时间run_date、执行器类型executor_type、任务函数路径func_path、任务参数args/json_args、是否启用enabled、任务状态status、最近执行时间last_run_time、下次执行时间next_run_time。任务函数路径func_path是一个字符串例如apps.jobs.sync_data.run。调度器在执行时通过 importlib 动态导入该路径对应的函数来调用。这种设计的好处是后台管理界面新建任务时不需要写代码只要填入一个指向已有函数模块的字符串即可。缺点是在任务提交时无法在界面上做完整的函数存在性校验只能在真正执行时通过 TaskRunError 体现。这一点在实际使用时需要有意识地进行提示。3.3 管理后台支持的操作能力FastapiAdmin 的管理后台针对定时任务通常提供了五类操作查看任务列表、新建任务、编辑任务修改触发器参数、启停任务、删除任务、手动执行一次。这五个操作看上去简单但在实现上与调度器 API 的对应关系相当直接。查看任务列表直接查询数据库中的任务配置表展示任务的基础信息和下次执行时间。新建任务把界面表单参数转换成 APScheduler 的 add_job 参数创建 job。编辑任务先 remove 旧任务再按新参数 add_job。删除任务remove job 并从数据库删除记录。手动执行一次调用 job 的函数直接运行不影响原定的调度计划。手动执行这个功能在实现上有一个值得注意的点直接走调度器接口修改下次执行时间并不合适正确的做法是单独拉一个函数出来通过函数模块调用。FastapiAdmin 中实现此功能时通常是读取任务配置后导入 func_path 指定的函数并执行这样不会污染已经排定的调度计划。4. 新建定时任务全流程实操原理说了这么多还是得到真实的环境里跑一遍才能彻底吃透。下面按 FastapiAdmin 中新建一个定时任务的实际操作流程走一遍重点标注每一步里面的核心要点和容易踩的坑。4.1 新建任务的完整数据字段说明首先打开定时任务管理页面点击新建任务会出现一个表单。这个表单通常包含以下关键字段任务名称建议用能表达任务用途的名称比如sync_product_stock_daily。注意这个名称在 APScheduler 中作为 job_id 使用如果已有同名任务直接新建会抛冲突异常。FastapiAdmin 的处理方式一般是在提交前检查任务名是否重复但如果你直接调 API 接口绕过了界面校验就会遇到ConflictingIdError数据库里会出现同名的脏数据。触发器类型下拉选择 cron、interval、date 三选一。这一步决定了后续展示哪些字段比如选了 cron就要填分、时、日、月、周等 cron 参数选了 interval就要填间隔秒数。cron 表达式字段FastapiAdmin 一般是把秒、分、时、日、月、周拆成多个输入框用户分别填。这种设计比单文本框填完整 cron 表达式要友好得多。各输入框的说明秒0-59cron 的秒位。默认填 0。分0-59分钟位。如果希望每分钟执行一次这里填*如果希望每 5 分钟执行一次填*/5。时0-23小时位。日1-31日位不指定填*。月1-12月位不指定填*。周0-60 表示周日周位不指定填*。注意日和周在 APScheduler 中如果同时指定都不为*会按两者的并集执行这与部分 Linux 发行版中的 crontab 行为取交集不同。为了避免理解偏差建议在界面提示中说明日和周同时指定时满足任意条件即执行。间隔秒数如果触发器选择了 interval这一步填执行间隔单位是秒。例如想每 5 分钟同步一次间隔秒数填 300。这里有一个细节APScheduler 的 interval 触发器支持用 timedelta 对象来表示非常灵活的间隔例如每周一执行但在 FastapiAdmin 界面里通常只开放秒级的间隔输入框复杂的 interval 需求建议配合 cron 触发器实现。执行器类型选择线程池还是进程池。大多数业务场景如同步数据、发送通知都属于 IO 密集型选线程池即可。如果任务里有大量 CPU 计算且不依赖共享状态选进程池。任务函数路径填写项目中已经存在的函数模块路径。这是最容易出错的字段因为拼写错误只有在任务真正执行时才能暴露。建议在新建表单旁边加上功能引导用户从已有函数列表中选择辅助填入路径。任务参数用于把额外参数传给任务函数。可以是 JSON 字符串如{api_url: http://example.com/data, limit: 100}。在调度器中添加 job 时将 JSON 反序列化为 dict并通过 kwargs 传入。4.2 JS 端提交逻辑与 API 交互在 FastapiAdmin 的后台界面中定时任务管理的前端页面会使用 JavaScript 发起提交请求。其核心过程是前端在提交表单前先根据所选触发器类型把 cron 表达式的各字段拼接为一个完整的 cron 字符串例如0 0 */1 * * *。如果是 interval 触发器则把间隔秒数转为整数。组装一个 JSON 请求体POST 到定时任务列表接口如/api/jobs携带任务名称、触发器类型、cron 表达式、间隔秒数、任务函数路径、任务参数等数据。这里有一个不太直观的细节cron 表达式的字段拼接顺序必须严格按照 APScheduler 的second minute hour day month day_of_week顺序。如果前端拼接顺序错了例如把秒放最后那么每天固定时间执行的 cron 表达式会变成在错误的时刻触发。我在实际项目中见过不少这种情况用户填了 8:30结果任务在 30 分 8 秒的时候执行了——就是因为前端把秒位当成了最后一位拼接。这种情况下解决方案是前端拼好字符串后传给后端时后端在 add_job 前做一个 cron 表达式的解析验证如用 croniter 库如果解析失败直接在接口层返回错误提示cron 表达式格式有误而不是等到任务真正执行时才报错。4.3 Cron 表达式详解与常用示例cron 表达式是整个定时任务配置里最核心也最容易出错的部分。为了让读者能够快速建立直觉这里用生活化类比说明一下cron 表达式相当于一个日历闹钟每个字段对应日历上的一个维度秒、分、时、日、月、周每个维度都可以指定是精确值、范围、步长还是通配符。当所有维度的匹配条件都满足时这个闹钟才会响。以下几个示例可以直接抄作业执行需求cron 表达式秒 分 时 日 月 周说明每 5 分钟执行一次0 */5 * * * *整分钟触发秒位固定为 0每天凌晨 2:30 执行0 30 2 * * *时分固定日/月/周通配每周一早八点执行0 0 8 * * 1周位填 1 表示周一每月最后一天 23:59 执行0 59 23 L * *L 表示最后一天APScheduler 支持的扩展语法工作日工作时间每半小时执行0 */30 9-18 * * 1-5范围用 -步长用 /工作日周一到周五每 10 秒执行一次*/10 * * * * *秒位使用步长这里要提醒一个在使用中容易忽略的点APScheduler 默认会把缺失的高位字段自动填充为 0这与标准 crontab 默认填充方式略有差异。处理原则是不论哪种方式建议始终把 6 个字段写完整避免出现我以为没填就是任何时间实际上被自动填充成了 0的歧义。5. 任务执行链路与运行日志追踪配置好任务之后接下来需要搞清楚任务从被触发到运行完毕的完整链路这样在排查问题时才能有方向。5.1 从调度到执行的完整链路APScheduler 内部的任务执行链路大致分五步调度器主循环唤醒调度线程每 0.1 秒左右醒来一次遍历所有注册的 job。检查 job 的 next_run_time 是否小于等于当前时刻如果小于等于则认为需要触发执行。将 job 提交给执行器执行器是 ThreadPoolExecutor 或 ProcessPoolExecutor它的内部维护一个任务队列。执行器启动线程或进程执行 job 中保存的 func 函数这是用户任务代码真正被执行的阶段。任务执行完成后调度器更新 job 的 next_run_time并记录 misfire错过的执行情况。这五步中最容易出问题的是第 2 步和第 4 步。第二步的问题场景是任务本该在 10:00:05 执行但是调度线程 10:00:04.995 扫描时发现没到时间等到下一次 10:00:05.100 扫描时才触发这个十几毫秒的误差是正常的。但如果调度器本身被阻塞大量任务同时在跑这个误差会急剧放大导致任务执行时间明显偏移。第四步的问题场景是任务函数本身执行时间太长比如一个网络请求超时卡了 120 秒线程池中的线程被长期占用。默认线程池大小只有 10如果同时有 10 个以上的长任务在跑新任务就会排队等待。FastapiAdmin 在调度器初始化时通常会调大线程池但如果任务里有恶性超时逻辑调大线程池也只是延缓问题爆发更好的做法是在任务函数内部设定一个合理的请求超时时间如 10 秒超时则快速失败。5.2 执行结果与状态流转在执行链路中任务的状态流转也是一个关键观察点。FastapiAdmin 的任务状态一般使用以下几种值waiting已注册到调度器等待第一次触发。running正在执行中通常由线程池执行器反馈。success最近一次执行成功这是由 FastapiAdmin 的任务执行包装逻辑写入的APScheduler 本身不记录执行结果它只知道任务是否被触发不知道业务代码是否成功了。failed最近一次执行异常异常消息会被捕获并写入任务日志表。这里有一个非常常见的问题为什么我的任务明明被执行了状态却是 failed大概率原因是任务函数内部抛出了未被捕获的异常而 APScheduler 默认的行为是把异常捕获后记录然后继续等待下一次触发。FastapiAdmin 在此基础上做了增强把异常信息记录到任务日志表然后把任务状态更新为 failed。但有个盲区——如果任务函数本身是异步函数async def而线程池执行器并不支持直接运行协程对象就会报TypeError: An asyncio.Future, a coroutine or an awaitable is required。解决办法是在任务函数字符串路径中指向一个同步的包装函数内部用 asyncio.run 来执行真正的协程。5.3 使用日志表回溯异常现场在排查线上任务异常时FastapiAdmin 的任务日志表设置通常比任务表更详细。每个任务执行时会记录以下信息任务 ID、任务名称、开始时间、结束时间、执行耗时毫秒、执行状态、异常信息如果有。当任务失败时异常信息一栏会保存完整的 traceback 字符串。我在实际操作中的经验是只要任务执行失败率超过一定阈值就应该第一时间去日志表里确认异常信息而不是在任务配置里反复检查 cron 表达式。因为大多数情况下任务配置是正确的问题出在任务代码本身——比如上游 API 变更导致返回数据结构不同、数据库连接池被耗尽、某个依赖服务临时不可用这些情况只能靠日志表还原现场判断。6. 常见问题与排查技巧实录定时任务模块上线后最耗时间的往往是各种莫名其妙的现场问题。这里把几个高频问题整理成速查表附上排查思路和解决建议。6.1 任务到了时间却不执行这是最高频的问题原因分布大致如下可能原因判断方法解决方案任务未启用查看任务状态字段是否 enabled在管理界面勾选启用或通过 API 更新状态调度器去重冲突服务重启后同一任务被注册了两次旧任务已除名检查启动日志中的 job store 加载记录进程未启动检查服务进程日志确认 scheduler.start() 是否被调用在启动流程中补上调度器启动步骤cron 表达式错误用 croniter 验证表达式是否能解析出未来的执行时刻修正表达式或改用表单化输入任务函数路径错误手动通过 python 命令行导入该函数路径修正函数路径并在提交时做路径预检查排查这类问题时我习惯先看调度器启动日志确认任务是否成功注册。如果注册成功但没执行就检查 cron 表达式的解析结果。如果解析结果正确但到点没触发就用调试模式在_process_jobs处打日志查看调度循环计算的 next_run_time。这套排查顺序几乎能覆盖 80% 以上的不执行场景。6.2 任务重复执行重复执行的问题比不执行更隐蔽因为不执行是静默的重复执行往往伴随着数据异常才被注意到。常见的重复执行原因有FastAPI 服务启动了多个 worker 进程如uvicorn --workers 4每个 worker 都初始化了一个调度器实例任务被注册了四份到点四个进程同时执行同一个任务。手动触发接口被重复调用而接口内部没有做幂等控制。代码中在多个地方调用了 scheduler.start()。解决方案比较明确在生产环境中定时任务模块所在的调度器只允许在一个进程中运行。如果你的 FastAPI 服务明确需要使用多 worker 扩容那么要么把定时任务拆分成一个独立的单 worker 服务要么引入一个分布式锁确保同一时刻只有一个 worker 的调度器在运行。FastapiAdmin 实践中更常见的做法是在自己部署 FastAPI 服务时单独跑一个进程承载定时任务模块或者让启动参数强制设为 1 个 worker视具体部署方式而定。6.3 长时间任务阻塞调度器当任务执行时间较长且并发数量较多时线程池会被占满新任务的触发时间会被严重延后表现为任务到点了但是很晚才真正执行。排查时重点看两件事第一当前线程池的活跃线程数。如果长期打满优先考虑调大线程池大小。第二是否有某个任务的执行时间远超预期。如果有在任务函数里加上超时控制——比如网络请求用timeout(5, 10)参数数据库操作设置innodb_lock_wait_timeout等。超时控制的意义不在于解决业务逻辑问题而在于避免一个坏任务把整个调度器的执行能力耗尽从而影响其他健康任务。还有个容易被忽略的细节如果多个任务执行的是同一个外部接口而这个接口本身响应很慢那么这些任务会抢占线程池。最直接的办法是任务内部做限流使用信号量或者对接口做缓存。这一点在同步外部数据源的场景里格外重要。6.4 服务重启后任务配置丢失服务重启后任务配置丢失通常是 Job Store 配置不当导致的。如果 task list 页面的数据是通过内存 List 临时存储、没有持久化到数据库那么进程重启后这些数据自然就没了。判断标准很简单直接在数据库中查询任务配置表看是否有数据。如果有数据但重启后调度器没有恢复任务那大概率是 Job Store 与数据库表没有正确绑定。FastapiAdmin 中正确做法是在 scheduler 初始化时指定 SQLAlchemyJobStore 并绑定到同一个数据库连接这样任务配置表本身就是调度器的持久化载体两者天然同步。6.5 时区导致的任务时间错乱时区问题通常不太显眼但一旦出现表现就是我明明填了 14:00却一直显示 22:00 执行之类的诡异现象。APScheduler 中时区设置有两个层级调度器全局时区和任务单独时区。FastapiAdmin 在初始化调度器时应该统一将 timezone 参数指定为Asia/Shanghai或项目部署地的时区同时所有任务的 timezone 不单独指定沿用全局设置。这样最省心。如果已经出现时区错乱排查时先用scheduler.timezone查看实际时区确认是否与预期一致再检查数据库中 TaskRecord 的创建时间是否也是按同一时区写入的。注意 SQLAlchemy 读写时间字段时如果数据库连接配置了use_db_conn_timezone之类的参数可能进一步导致时区偏移这类问题已经在多个项目里困扰过不少人。7. 实操经验与扩展建议FastapiAdmin 的定时任务模块在实际落地过程中我积累了不少心得这里挑三个比较有代表性的分享。第一个心得是任务函数一定要做得足够短且无状态。看似简单的原则真正做到很难。比如一个数据同步任务正确做法是把同步逻辑拆成两段定时任务只负责触发的入口把真正的同步任务推送到一个队列中由后台工作者处理。这种设计的好处是即使某个任务的执行耗时很长也只影响执行它的线程不会阻塞调度器的其他任务触发。如果是单机项目用一个简单的 FIFO 队列就能实现这个方案。第二个心得是执行结果一定要留痕。APScheduler 本身不关心任务执行的结果如果业务上需要知道任务到底是成功还是失败、耗时多久、处理了多少条数据就需要在任务函数内部自己记录日志。FastapiAdmin 的任务日志表天然支持这个需求。我建议在每个任务函数里至少记录两行日志任务开始时记录起始时间和入参摘要任务结束时记录耗时、处理数量和异常摘要。这样排查问题时就不需要去翻业务模块的日志直接在任务管理页面就能看到完整的执行链。第三个心得是针对 cron 表达式要做预校验。很多后台管理系统的定时任务表单只是简单地把用户填写的表达式存进数据库等到真正执行时才发现格式不对。FastapiAdmin 在提交任务时一定要在服务端用 croniter 或 APScheduler 的 CronTrigger.from_crontab 方法校验表达式是否合法。这个校验成本不高但能非常有效地降低运维成本。如果你对定时任务的扩展方向有兴趣可以朝这几个方向深入一是把任务上下次执行时间的数据缓存起来做一个任务日历展示方便运营人员直观看到未来一段时间内任务的执行计划二是接入 Celery 或 RQ 作为分布式执行引擎让调度与执行彻底解耦三是做一个任务失败自动重试机制在任务失败后做指数退避重试。每个方向都很有实用价值但前提是需要先把 FastapiAdmin 定时任务本身的基础原理吃透。