RQ不是轻量版Celery，而是为特定场景设计的极简任务队列；常见问题包括未启动Redis、队列名不匹配、模块导入失败、timeout与result_ttl混淆、部署环境路径错误及缺乏重试/优先级等高级功能。
RQ（Redis Queue）不是“轻量版 Celery”，它压根没想做通用任务队列，而是为特定场景设计的极简工具——用对了很顺手，用错了连错误都报得模棱两可。
为什么 rq worker 启动后立刻退出或不消费任务
常见现象是终端一闪而过、日志里没看到 Listening on default，或者明明 q.enqueue(func) 成功了但函数死活不执行。
- 最常踩的坑：没启动 Redis 服务，或
RQ_REDIS_URL指向了错误地址（比如本地没开redis-server，却配成redis://localhost:6379） - RQ 默认只监听
default队列，如果代码里用了Queue('myqueue')，就得显式运行rq worker myqueue，否则 worker 压根不看这个队列 - worker 进程依赖当前 Python 环境能 import 到任务函数——函数定义在
main.py里、又没打成包，直接跑rq worker就会报ImportError，必须把模块路径加进PYTHONPATH或改用rq worker --path .
rq 的 timeout 和 result_ttl 到底管什么
这两个参数看着像超时控制，实际分工很明确，混淆就会导致任务“消失”或“卡住”。
-
timeout（传给q.enqueue(func, timeout=30)）：只限制函数执行时间，超时后 Redis 里任务状态变failed，但结果不会自动删 -
result_ttl（默认 500 秒）：控制结果在 Redis 里存多久，过期后job.result返回None，哪怕任务本身成功了——查不到结果不等于没执行 - 如果任务耗时长又不想丢结果，得同步调大两者：
q.enqueue(func, timeout=300, result_ttl=3600)；但注意result_ttl太大会撑满 Redis 内存
为什么本地开发没问题，部署到服务器就 Job failed: No module named 'xxx'
这不是 RQ 的 bug，是 Python 模块加载机制和部署环境差异共同导致的。
立即学习“Python免费学习笔记（深入）”；
- RQ worker 启动时的工作目录决定
sys.path，如果用 systemd 启动，WorkingDirectory没设对，import就会失败 - 函数被序列化时只存模块路径和函数名（如
'tasks.add'），不打包字节码——所以 worker 环境必须有完全一致的包结构和版本 - 推荐做法：把任务函数放在独立模块（如
tasks.py），用rq worker --path /opt/myapp显式指定路径，避免依赖当前目录
真正麻烦的是任务中间状态不可控：RQ 没有重试退避、没有优先级队列、不支持任务依赖。一旦需要这些，硬加补丁比换工具更费劲——它从设计上就没打算处理复杂调度逻辑。
