django-crontab不能直接清理Django缓存，因其仅注册定时任务而不具备缓存扫描能力；清理逻辑需自行实现，依赖key命名规范与主动删除，避免使用keys(*)等禁用命令。
为什么 django-crontab 不能直接清理 Django 缓存？
Django 的缓存（如 LocMemCache、RedisCache）本身不暴露“过期键列表”，django-crontab 只是把 Python 函数注册为系统 crontab 任务，并不提供缓存扫描能力。你写的清理逻辑，得自己负责判断哪些缓存过期、怎么删——框架不会帮你自动识别。
常见误区是以为加了 'schedule': '0 2 * * *' 就能自动清缓存，其实只是定时调用你写的函数，函数里没写对逻辑，照样无效。
-
django-crontab不感知 Django 缓存后端的内部结构，比如 Redis 中的 key 过期时间是服务端控制的，Python 层无法批量查“哪些已过期” - 如果用
LocMemCache，进程重启就全丢，根本不需要手动清理；但生产环境多用 Redis 或 Memcached，得靠 key 命名规范 + 主动删除 - 别依赖
cache.keys('*')—— 多数后端（包括默认 Redis 配置）禁用KEYS命令，会报ResponseError: BUSY redis is busy running a script或权限拒绝
如何写一个安全可执行的缓存清理函数？
核心思路：不扫全量 key，而是按业务约定前缀 + 时间戳标记来清理。例如，把用户 session 缓存设为 user_session_123_20240520，过期后通过前缀 + 日期范围批量删。
示例函数（放在 management/commands/clear_expired_cache.py）：
A Python CLI skill for Cutout.Pro visual APIs — background removal, face cutout, and photo enhancement. Supports file upload & image URL input.
下载
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强，支持文件上传与图片 URL 输入。
立即学习“Python免费学习笔记（深入）”；
from django.core.management.base import BaseCommand
from django.core.cache import cache
import re
<p>class Command(BaseCommand):
def handle(self, *args, **options):</p><h1>只清理带日期后缀且早于昨天的 key（需确保你的 set 逻辑写了日期）</h1><pre class='brush:python;toolbar:false;'> prefix = 'user_session_'
cutoff_date = (timezone.now() - timedelta(days=1)).strftime('%Y%m%d')
# Redis 实际不支持正则，这里用 scan 模拟（仅限开发环境验证）
# 生产请改用 pipeline + scan 匹配 prefix*，再逐个 check ttl
keys_to_delete = [k for k in cache._cache.scan_iter(f'{prefix}*')
if re.search(r'_\d{8}$', k) and k.endswith(cutoff_date)]
if keys_to_delete:
cache.delete_many(keys_to_delete)</pre>- 不要在函数里用
cache.get(key)判断是否过期——已过期的 key 返回None，但无法区分“不存在”和“已过期” - 优先用
cache._cache.ttl(key)（Redis 后端）或cache._cache.pttl(key)查剩余时间，比 get 更准 - 如果用数据库缓存（
DatabaseCache），可直接 SQL 删除：DELETE FROM django_cache WHERE expires ，但注意表名可能带前缀
配置 django-crontab 时容易漏掉的关键项
很多人跑不起来，不是代码问题，而是配置没生效。重点检查三处：
- settings.py 中必须有
CRONJOBS = [('* * * * *', 'myapp.management.commands.clear_expired_cache.Command')]—— 路径要到Command类，不是模块名 - 运行
python manage.py crontab add后，用crontab -l确认生成的行是否包含你的项目manage.py绝对路径，否则找不到 Django 环境 - Linux 用户权限问题：如果用 systemd 或 supervisor 托管 Django，crontab 默认跑在 root 下，可能读不到你的
.env或虚拟环境，建议显式指定解释器：*/5 * * * * /path/to/venv/bin/python /path/to/project/manage.py clear_expired_cache
替代方案比 django-crontab 更适合缓存清理？
如果你的缓存清理逻辑复杂（比如要结合数据库状态、API 调用结果），或者需要失败重试、日志追踪、并发控制，django-crontab 就显得单薄了。
-
celery beat+celeryworker 是更稳的选择：支持 task retry、result backend、beat 调度精度到秒，且天然兼容 Django context - Redis 自身 TTL 机制足够可靠时，根本不用 Python 层清理——只要 set 时明确传
timeout=3600，Redis 会自动驱逐 - 部分场景更适合“懒清理”：比如用户登录时检测 session 缓存是否有效，无效则删并重建，避免定时任务争抢资源
真正难的不是加一行 crontab，而是确认“哪些缓存该被清理”“清理时机是否影响请求响应”“失败了有没有告警”。这些没法靠工具自动解决。
