APScheduler在Flask/Django多进程部署下会重复执行任务，因每个worker独立启动scheduler；应剥离scheduler至单独进程或限定仅主进程运行，并用PostgreSQL/Redis替代SQLite存储，且job中需显式管理应用上下文。
APScheduler 不能直接在 Flask/Django 等 Web 框架里“热启动”定时任务，尤其在多进程部署（如 gunicorn + 多 worker）下，任务会重复执行——这是最常踩的坑，不是代码写得不对，而是部署模型没对齐。
为什么 Flask 中直接 new BackgroundScheduler() 会出问题
Flask 开发服务器默认开启 debug=True 时是单进程+重载机制，BackgroundScheduler 看似能跑；但一旦用 gunicorn --workers 4 启动，每个 worker 进程都会独立初始化一个 scheduler，导致同一任务被并发执行 4 次。Django 的 runserver 同理，正式部署（如 uWSGI）后也一样。
- 不加任何保护机制的
BackgroundScheduler().start()在多 worker 下必然重复触发 -
BlockingScheduler会阻塞整个 Web 进程，HTTP 请求全卡住，完全不可用 - 即使加了
if __name__ == '__main__':判断，gunicorn 仍会为每个 worker 执行模块顶层代码
只允许一个 scheduler 实例运行的两种可靠做法
核心思路：把 scheduler 剥离出 Web 进程，或强制限定仅由一个进程接管。推荐以下两种实际验证过的方案：
- 用单独的 Python 脚本启动
BackgroundScheduler，通过 Redis 或数据库共享状态（如任务开关、上次执行时间），Web 接口只负责配置变更，不参与调度逻辑 - 在 Web 应用中加进程标识判断：例如用
os.environ.get('WERKZEUG_RUN_MAIN') == 'true'（仅 Flask 开发模式有效），或更通用的——检查是否为 gunicorn 的主进程：os.getenv('IS_GUNICORN_MASTER', 'false') == 'true'，需配合 gunicorn 的--preload和自定义on_startinghook 设置该环境变量
后者实操性更强，但要注意：Django 没有等价钩子，必须改用外部进程方案。
立即学习“Python免费学习笔记（深入）”；
如何让 APScheduler 任务安全访问 Web 应用上下文（如 Flask app 或 Django ORM）
APScheduler 的 job 函数默认运行在独立线程中，current_app 或 Django 的 django.db 会报 “working outside of application context” 或 “DatabaseWrapper is not initialized” 错误。
- Flask 场景下，job 函数开头必须显式调用
app.app_context().__enter__()，并在结尾__exit__()，或用with app.app_context():包裹业务逻辑 - Django 场景下，job 函数开头加
django.setup()（仅首次需要），且每次操作 DB 前确保django.db.connection.ensure_connection() - 避免在 job 中长期持有 Flask
request对象或 Djangorequest——它们只存在于 HTTP 生命周期内，定时任务里根本不存在
示例片段（Flask）：
def my_job():
with app.app_context():
user = User.query.filter_by(active=True).first()
send_notification(user)
使用 SQLite 作为 APScheduler 的 jobstore 会崩溃
SQLAlchemyJobStore 默认用 sqlite:///jobs.sqlite 时，在多进程下会因文件锁冲突直接抛 OperationalError: database is locked，哪怕只读操作也可能失败。
- SQLite 不支持多进程并发写入，APScheduler 的 jobstore 读写频繁，绝对不能用于生产
- 必须换用支持并发的数据库：PostgreSQL（推荐）、MySQL，或轻量级替代方案
RedisJobStore（需装apscheduler[redis]） - 若坚持用 SQLite，只能搭配单进程部署（如 Flask dev server），且必须设置
coalesce=True和max_instances=1防重入，但依然不保证可靠性
Redis 示例初始化：
from apscheduler.jobstores.redis import RedisJobStore
jobstores = {'default': RedisJobStore(host='localhost', port=6379, db=1)}
真正麻烦的从来不是怎么写 schedule.add_job()，而是部署时进程模型、数据存储、上下文生命周期这三者的对齐——漏掉任意一环，上线后要么任务不跑，要么跑十遍，要么数据库锁死。
