schedule.run_pending()需手动循环调用，否则只执行一次；须配合while True和time.sleep()避免CPU占用或延迟；Web服务中应放后台守护线程运行；job异常会中断所有任务，需try/except或装饰器兜底；复杂场景建议换APScheduler。
schedule.run_pending() 为什么没反应？
根本原因：它只是检查并执行一次待触发任务，不自动循环。你得自己加个 while True 配合 time.sleep()，否则脚本跑完就退出，定时器压根没机会干活。
- 常见错误现象：
schedule.every(10).seconds.do(job)写了，但程序启动后啥也不输出、没执行 - 必须手动轮询：在主逻辑里持续调用
schedule.run_pending()，比如每秒检查一次 -
time.sleep(1)是关键——不加会疯狂占用 CPU；设太长（如 5 秒）会导致任务延迟最多达该间隔 - 别用
time.sleep(0)或pass循环，那是空转，等同于没 sleep
怎么避免阻塞主线程（比如 Flask/FastAPI 服务）？
schedule 本身是同步的，直接丢进 Web 框架主线程里跑，等于把整个服务卡住。真要共存，得把它扔进独立线程里跑，且线程得设为 daemon=True，不然主程序关不掉。
- 典型错误：在
app.run()前写个while True，结果 Web 服务根本起不来 - 正确做法：用
threading.Thread启一个后台线程，里面跑schedule.run_pending()+time.sleep() - 务必加
thread.daemon = True，否则 Ctrl+C 时线程还在后台活着，进程杀不干净 - 示例片段：
import threading<br>def run_scheduler():<br> while True:<br> schedule.run_pending()<br> time.sleep(1)<br>t = threading.Thread(target=run_scheduler)<br>t.daemon = True<br>t.start()
job 函数抛异常会导致后续所有任务停摆吗？
会。schedule 不做异常隔离，默认一崩全停。哪怕只是某个 job 里写了 1/0，之后所有定时任务都再不会执行。
- 常见现象：某次日志报
ZeroDivisionError后，后续本该每分钟跑的任务彻底静默 - 解决方法：在每个 job 函数内部包一层
try/except，至少 catchException，别让它冒出去 - 不要依赖 schedule 自带的错误处理——它没有
- 如果需要统一兜底，可封装一个装饰器：
def safe_job(func):<br> def wrapper(*args, **kwargs):<br> try:<br> return func(*args, **kwargs)<br> except Exception as e:<br> print(f"Job {func.__name__} failed: {e}")<br> return wrapper<br><br>@safe_job<br>def my_task():<br> ...
schedule 和 APScheduler 到底选哪个？
看需求复杂度。schedule 就是“够用就行”的轻量选择；一旦要持久化、分布式、精确到毫秒或失败重试，立刻换 APScheduler。
立即学习“Python免费学习笔记（深入）”；
- schedule 优势：零依赖、代码少、易读易改，适合单机脚本、开发期临时轮询、CI 中简单触发
- schedule 劣势：无任务状态管理、不支持 misfire 处理、不能跨进程、时间精度受
sleep间隔限制 - APScheduler 适合场景：生产环境长期运行、需存储任务状态（比如用 SQLAlchemy）、要和 Celery 配合、要求错过时间后自动补跑
- 别为了“看起来更专业”硬上 APScheduler——多出 3 个依赖、配置项翻倍、出问题排查路径更长
