不能直接用 Django management command 配 cron，因 cron 调度进程导致频繁重建应用上下文，引发数据库连接池卡死、信号重复加载、无状态追踪与失败重试等问题；Celery+Redis 最小配置需对齐 broker 与 result backend 的 Redis DB、启用任务跟踪与延迟确认，并将任务定义在可被 autodiscover_tasks 扫描的 tasks.py 中，避免循环依赖。
为什么不能直接用 Django 自带的 management command 配 cron？
因为 cron 调度的是进程，不是 Python 对象；Django 的 manage.py 每次启动都重建整个应用上下文，频繁调用会卡住数据库连接池、重复加载信号、触发中间件初始化——尤其在高频率任务（比如每分钟一次）下，容易出现 ConnectionResetError 或 django.db.utils.OperationalError: database is locked。
更关键的是：cron 无法感知任务是否真正执行成功、失败后不重试、没有任务状态追踪、也不能跨机器分发。你得自己写日志轮转、失败告警、并发锁……这些本该由任务队列解决的事，硬塞给 shell 脚本只会越搞越重。
Celery + Redis 最小可行配置怎么写？
别一上来就抄官网完整配置。先确保这三处对齐：
-
CELERY_BROKER_URL = 'redis://127.0.0.1:6379/0'—— 必须显式指定 DB 编号，Redis 默认 DB 是 0，但很多本地环境被其他服务占了，连错库会导致ConnectionRefusedError -
CELERY_RESULT_BACKEND = 'redis://127.0.0.1:6379/1'—— 结果存储建议和 broker 分开 DB，避免任务元数据和结果混在一起，查起来乱 -
CELERY_TASK_TRACK_STARTED = True和CELERY_TASK_ACKS_LATE = True—— 前者让任务状态可查，后者防止 worker 挂掉时任务丢失（默认是早确认）
示例：@shared_task(bind=True, max_retries=3, default_retry_delay=60) 这种装饰器里加 bind=True 才能在函数里用 self.retry()，否则报 AttributeError: 'NoneType' object has no attribute 'retry'。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
定时任务写在 celery.py 还是 tasks.py？
必须写在 celery.py 同级的 tasks.py 里，且模块能被 Django 自动发现（比如放在某个 app 下）。Celery 启动时靠 app.autodiscover_tasks() 扫描，如果把 @shared_task 直接写在 celery.py 里，第一次 import 就会触发循环依赖——celery.py 导入 django.conf.settings，而 settings 又可能导入 apps，apps 又尝试导入 tasks，tasks 又要 import celery app……最终卡死在 ImportError: cannot import name 'app' from partially initialized module。
常见错误现象：celery -A myproject worker -l info 启动后没报错，但 inspect scheduled 看不到任务，或者 celery beat 报 KeyError: 'mytask'。这时候八成是路径没对上，检查 INSTALLED_APPS 是否包含该 task 所在 app，再确认 app.autodiscover_tasks(['myapp']) 是否显式声明。
Beat 启动时报 PermissionError: [Errno 13] Permission denied 怎么办？
这不是 Celery 的错，是 beat 尝试写 celerybeat-schedule 文件时权限不够。默认它会生成在当前工作目录，如果你用 systemd 或 docker 启动，工作目录可能是 / 或只读路径。
- 加参数指定位置：
celery -A myproject beat --schedule=/var/run/celery/celerybeat-schedule - 确保目录存在且可写：
mkdir -p /var/run/celery && chown celery:celery /var/run/celery - 更稳妥的做法是禁用文件调度，改用数据库：装
celery-beat-db，配CELERY_BEAT_SCHEDULER = 'celery_beat_db.schedulers.DatabaseScheduler'，然后python manage.py migrate
注意：celery beat 和 celery worker 必须共用同一个 broker URL，否则 beat 发的任务，worker 根本收不到——这种问题不会报错，只会“静默丢任务”，特别难排查。
最常被忽略的一点：Redis 的 timeout 参数。如果设得太小（比如默认 0），连接空闲几秒就被 server 断开，worker 会持续打印 Connection closed by server，然后反复重连。在 CELERY_BROKER_URL 后面加上 ?socket_timeout=5&socket_connect_timeout=5 才算稳。
