schedule：Python 定时任务，就这一行

schedule 在 GitHub 上已拿到 12,247 Star。

Python 的定时方案很多。cron 语法对很多人不够友好，APScheduler 配置偏重，Celery 需要消息队列和结果后端，每加一个依赖项目就重一分。如果需求只是让一个函数每十分钟跑一次，或者每天十点半执行某个脚本，schedule 把这件事做到了最简。

设计思路

schedule 的目标明确：用代码本身来表达定时逻辑。不需要 YAML 配置文件，不需要启动额外进程，不需要消息中间件。pip install 之后，在脚本里写几行就能跑。

整个库就是一个文件，没有任何外部依赖。项目测试覆盖了 Python 3.7 到 3.12，维护一直在持续。安装包只有十几 KB，引入项目几乎零成本。轻量是它和 Celery、APScheduler 这类工具最根本的区别。

API 风格

API 的设计读起来就是自然语言：

• every(10).minutes - 每 10 分钟执行一次
• every().day.at(“10:30”) - 每天 10 点 30 分执行
• every().monday - 每周一执行
• every(5).to(10).minutes - 每隔 5 到 10 分钟随机间隔
• every().minute.at(“:17”) - 每小时的 17 分执行
• every().wednesday.at(“13:15”, “Europe/Amsterdam”) - 支持时区设置

每个表达式后面接 .do(job)，传入要执行的函数。也支持给函数传参数：

def job_with_argument(name):
    print(f"I am {name}")

schedule.every(10).seconds.do(job_with_argument, name="Peter")

最后需要一个循环来触发执行：

while True:
    schedule.run_pending()
    time.sleep(1)

schedule 的 run_pending() 本身不阻塞，会检查所有已注册的任务，到时间的就执行，然后立刻返回。sleep(1) 是为了避免 CPU 空转，每秒检查一次对 CPU 几乎无影响。在 Web 应用里也可以用线程或者异步方式集成，不一定要用 while 循环。

适用场景

适合脚本级别的定时需求：数据抓取、系统健康检查、日志清理、定时推送、文件备份。这些场景不需要分布式调度，不需要任务持久化，不需要重试机制。

如果需求更复杂，比如任务要持久化到数据库、需要在多台机器上协调执行、需要失败重试和管理后台，应该考虑 Celery 或 APScheduler。schedule 关注的是简单场景，在 GitHub 上累积的 12,000 多 Star 说明这种需求很普遍。用合适大小的工具解决问题，比什么都上重型框架更明智。

执行模型

schedule 的作业默认在同一个线程中串行执行。这意味着一个耗时的任务会阻塞后续任务的调度，直到它完成。如果作业有 IO 等待或者计算密集型操作，可以在任务函数内部使用多线程来解决。

这种设计取舍很清楚：简单情况下不需要考虑并发问题，代码更容易理解和维护。对于大多数脚本场景，串行执行已经足够。如果需要并发，Python 的 threading 或 asyncio 可以配合使用，schedule 在这层不做限制。

项目背景

作者 Daniel Bader 受 Adam Wiggins 的文章 “Rethinking Cron” 和 Ruby 的 clockwork 模块启发。他认为定时任务的表达方式应该是通用编程语言本身，cron 的领域特定语法增加了学习成本。用 Python 代码直接表达定时逻辑，比学一套新语法更自然。

这个库采用 MIT 协议，社区活跃，在 PyPI 上下载量很高，经受了大量生产环境的检验。

如果你需要一个轻量、无外部依赖的 Python 定时方案，schedule 值得一试。

载量很高，经受了大量生产环境的检验。

如果你需要一个轻量、无外部依赖的 Python 定时方案，schedule 值得一试。