APScheduler任务不执行的主因是jobstore选错、参数传递错误、主线程退出及任务无超时防护；需用SQLAlchemyJobStore持久化、kwargs/partial传参、event.wait()阻塞主线程、加timeout和max_instances防护。
APScheduler 的 jobstore 选错会导致任务不执行
APScheduler 默认用 MemoryJobStore，进程一重启，所有定时任务就彻底消失——这正是多数人发现“明明加了任务，但第二天爬虫没跑”的根本原因。
生产环境必须显式配置持久化 jobstore，比如用 SQLite：
from apscheduler.jobstores.sqlalchemy import SQLAlchemyJobStore
jobstores = {
'default': SQLAlchemyJobStore(url='sqlite:///jobs.sqlite')
}
-
SQLAlchemyJobStore支持多进程共享任务状态，适合部署在 systemd 或 Docker 中 - 避免用
RedisJobStore（需额外装apscheduler[redis]），除非你 already 有 Redis 且需要高可用调度 - SQLite 文件路径要确保进程有读写权限，否则启动时静默失败，
add_job看似成功，实则没存进去
add_job 传参不加 kwargs 会报 TypeError: crawl() takes 0 positional arguments but 1 was given
这是最常卡住新手的错误：直接把带参数的函数塞进 add_job，APScheduler 会自动补一个 job_id 当第一个位置参数，导致签名对不上。
正确做法只有两种：
立即学习“Python免费学习笔记（深入）”；
librosa Python 音频与音乐分析库
下载
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
- 用
kwargs显式传参：scheduler.add_job(crawl, 'interval', minutes=30, kwargs={'url': 'https://example.com'}) - 或用
functools.partial预绑定：from functools import partial; scheduler.add_job(partial(crawl, url='https://example.com'), 'interval', minutes=30) - 千万别写
add_job(crawl('https://example.com'), ...)——这会在添加时就执行函数，不是调度
使用 BackgroundScheduler 时主线程退出，任务立刻停摆
很多人写完脚本直接运行，发现几秒后就停了。因为 BackgroundScheduler 是后台线程，主线程结束，Python 解释器就退出，线程被强制终止。
必须阻塞主线程，但不能用 time.sleep(999999) 这种野路子：
- 推荐用
event.wait()等待信号：from threading import Event; event = Event(); event.wait() - 若配合 Flask/FastAPI，应改用
BlockingScheduler并在服务启动后调用.start()，避免线程冲突 - 在 Docker 或 systemd 中运行时，务必检查日志里有没有
Shutting down scheduler——那说明主线程提前结束了
爬虫任务卡死，APScheduler 不会自动重试或超时中断
APScheduler 本身不管理任务函数内部逻辑。如果 crawl() 因网络卡住、解析异常 hang 死，这个 job 就一直占着线程，后续同名 job 被跳过（默认 coalesce=True），整个调度节奏就乱了。
必须自己加防护：
- 给爬虫主逻辑套
try/except，捕获requests.exceptions.Timeout和concurrent.futures.TimeoutError - 用
requests.get(..., timeout=(3, 10))控制连接+读取超时 - 在
add_job里加max_instances=1，防止同一任务并发堆积 - 关键任务建议加日志记录开始/结束时间，方便排查是否真在跑还是假死
调度器只是发令枪，扣动扳机之后打不打得中、会不会卡壳，全看爬虫自己够不够健壮。
