APScheduler配置需选CronTrigger、显式设timezone='Asia/Shanghai'；爬虫函数须try/except捕获异常并logger.exception记录；日志用RotatingFileHandler配delay=True、绝对路径；启动后务必调start()并join主线程，持久化job需改用SQLAlchemyJobStore。
APScheduler 怎么配置每天固定时间执行爬虫任务
直接用 BackgroundScheduler + add_job 就能跑，但关键在触发器选对、时区设准、任务不重复。默认用 date 触发器只能跑一次，得换 CronTrigger 或 IntervalTrigger。
常见错误是本地时间 vs UTC 混淆：APScheduler 默认用系统时区，但如果你服务器在海外、代码部署在 Docker 里没配时区，hour=9 可能真在 UTC 9 点（即北京时间 17 点）运行。
- 用
CronTrigger(day_of_week='mon-fri', hour=9, minute=30)最直观，支持 cron 表达式所有语义 - 务必显式传入
timezone='Asia/Shanghai'，哪怕本地开发环境已设时区，Docker 容器里大概率没生效 - 避免用
IntervalTrigger(hours=24)模拟“每天”，它从首次启动开始倒计时，长期运行后会漂移
爬虫函数怎么写才不会被 APscheduler 吃掉异常
APScheduler 默认捕获并吞掉任务中抛出的异常，你根本看不到报错，日志里只有 “Job crashed” 一行，排查无从下手。
必须手动加 try/except 包裹主逻辑，并把异常写进日志——别依赖 logging.error 自动传播，scheduler 不转发。
立即学习“Python免费学习笔记（深入）”；
- 在爬虫函数开头加
logger = logging.getLogger(__name__)，用logger.exception("抓取失败")记录完整 traceback - 别在任务里调
sys.exit()或 raise 系统级异常（如KeyboardInterrupt），会导致 scheduler 主线程退出 - requests 超时必须设
timeout=(3, 7)，否则一个卡死请求会阻塞整个调度器
日志文件怎么按天轮转且不被多进程写乱
APScheduler 在单进程里是安全的，但如果你用 Gunicorn 启多个 worker，或后期改用 ProcessPoolExecutor 并发抓多个站点，日志就可能错行、覆盖、丢内容。
最稳方案是用 RotatingFileHandler 配合 delay=True，且禁止多进程共用同一个 FileHandler 实例。
- 不要用
TimedRotatingFileHandler，它在多进程下轮转逻辑不一致，容易生成app.log.2024-05-01和app.log.2024-05-01.1两份 - 每个爬虫任务函数内单独初始化 logger + handler，handler 设
delay=True，确保首次写日志时才创建文件 - 路径写绝对路径，比如
os.path.join('/var/log/mycrawler', f'crawl_{date.today()}.log')，避免相对路径在不同工作目录下失效
为什么 APScheduler 启动后任务没执行，连日志都不打
最常踩的坑是忘了调 .start()，或者调了但没 join() 住主线程——脚本一跑完就退出，scheduler 还没来得及触发第一次任务。
另一个隐蔽问题是 job store 用内存型（MemoryJobStore）时，程序重启 job 就消失，看着像“没执行”，其实是压根没注册成功。
- 确认写了
scheduler.start()，且后面有try: ... except KeyboardInterrupt: scheduler.shutdown() - 如果想持久化 job（比如机器重启后继续跑），必须换
SQLAlchemyJobStore，配好数据库 URL，光改jobstores字典不够，还得装sqlalchemy - 用
scheduler.print_jobs()打印当前注册的任务，看是否真加进去了——有时add_job报错被忽略，job 根本没注册
时区、异常捕获、日志初始化这三处，改一次能省两小时 debug 时间。其他都是语法细节，错也容易看出来。
