celery worker报importerror是因未在正确虚拟环境安装，flask上下文需显式传入或重建，异步任务应即发即走并轮询状态，定时任务需确保beat与worker共用同一broker且配置一致。
Flask里启动Celery worker报ImportError: No module named 'celery'
这不是Celery没装，而是当前Python环境没装，或者worker启动时用的不是项目所用的虚拟环境。很多同学在PyCharm里跑Flask没问题，一开终端跑celery -A tasks worker --loglevel=info就报这个错。
- 先确认是否在正确虚拟环境中：
which python和which celery输出路径要一致 -
pip install celery必须在该环境下执行，别漏掉redis或rabbitmq等broker依赖（比如pip install "celery[redis]"） - 如果用
celery -A tasks worker，确保tasks.py在Python路径下可导入——常见坑是把文件放在app/子目录却没加__init__.py或没把app设为包
Flask上下文在Celery任务里拿不到current_app或db
Celery worker是独立进程，不共享Flask应用实例。直接在任务函数里调current_app.config或db.session.add()会抛RuntimeError: Working outside of application context。
- 别在任务里硬写
from app import db然后直接用，得显式传入所需对象，比如：@celery.task def send_email(user_id): user = User.query.get(user_id) # 这行会崩 - 推荐做法：任务只接收原始参数（如
user_id、email），进任务后再初始化必要对象，或用工厂函数重建上下文（例如with app.app_context():） - 更稳妥的是把数据库操作封装成独立函数，在任务里调用，并确保它自己处理session生命周期（比如用
db.session.remove()收尾）
任务执行完但Flask接口返回前就结束了，导致前端收不到结果
Celery默认异步发任务后立刻返回task ID，不等结果。如果接口想“等结果再返回”，就得主动查——但别用.get()阻塞主线程，那跟没加Celery一样卡住HTTP请求。
- 典型错误：
result = long_task.delay().get(timeout=30)—— 这会让Flask请求挂起30秒，吞掉并发能力 - 正确姿势是“即发即走”：返回
{'task_id': task.id}，前端轮询/api/task-status/<task_id></task_id>，后端用AsyncResult(task_id).state和.result查状态 - 注意
AsyncResult查的是broker里的记录，所以broker（如Redis）必须和worker用同一个实例，否则查不到
本地开发时celery beat定时任务不触发
beat只是个调度器，它本身不执行任务，只往broker发消息；如果worker没起来、或broker配置和beat不一致，任务就永远躺在队列里不动。
- 检查
celery beat输出日志里有没有Writing entries...，没有说明schedule没加载成功（常见于CELERY_BEAT_SCHEDULE变量名拼错或没导出） - 确保
CELERY_BROKER_URL在beat和worker中完全一致，大小写、端口、DB号都不能差（比如Redis里用了db=1，beat却连db=0） - 本地调试建议加
--schedule /tmp/celerybeat-schedule，避免权限或路径问题导致schedule文件写失败
实际集成时最常被忽略的是broker连接的隔离性：开发、测试、生产必须用不同Redis DB或不同RabbitMQ vhost，否则本地worker可能悄无声息消费了线上任务，或者定时任务在多个环境互相干扰。这问题不报错，只“看起来不执行”，排查起来特别花时间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
