Django自定义管理命令需放在app的management/commands/下，定义继承BaseCommand的类并实现handle方法；删数据优先用QuerySet.delete()，支持参数化配置与定时安全执行。
怎么写一个可被 python manage.py 调用的清理命令
自定义管理命令本质是 Django 的一个约定目录结构，不是靠装饰器或注册表触发的。必须放在 management/commands/ 下，且文件本身要能被 Python 导入（不能有语法错误、不能叫 __init__.py 这种保留名）。
实操建议：
- 在某个已注册的 app 目录下新建
management/commands/clean_old_logs.py - 文件里必须定义一个继承
BaseCommand的类，类名随意，但必须叫Command -
handle(self, *args, **options)是唯一必重写的入口方法 - 别忘了在顶部 import 模型和
from django.core.management.base import BaseCommand
常见错误现象：Unknown command: clean_old_logs —— 大概率是路径不对、文件没放对位置、或者 app 没在 INSTALLED_APPS 里。
清理逻辑里怎么安全删数据，避免误删或锁表
Django 的 delete() 默认走 ORM 删除，会触发信号、逐条查再删，大数据量时慢且可能撑爆内存。真要清历史数据，得绕过 ORM 的“温柔模式”。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 优先用
Model.objects.filter(...).delete()，它生成单条 SQLDELETE FROM ... WHERE ...，不加载实例，快也省内存 - 如果条件复杂（比如跨表时间判断），改用
django.db.connection.cursor()手写原生 SQL，但务必用参数化防止注入 - 加个硬限制：比如
.filter(created_at__lt=timezone.now() - timedelta(days=90))[:10000]再 delete，避免一次删几百万行卡死数据库 - 生产环境一定要先
print(queryset.query)看生成的 SQL，确认 WHERE 条件写对了
性能影响：用 QuerySet.delete() 比 for + instance.delete() 快 10 倍以上；但若带 on_delete=CASCADE 关联，仍会触发外键级联删除，此时原生 SQL 更可控。
怎么让命令支持命令行参数，比如指定保留天数
参数不是靠 sys.argv 解析，Django 用的是 argparse 封装，必须在 add_arguments(self, parser) 方法里声明。
实操建议：
- 在
Command类里加add_arguments方法，调用parser.add_argument('--days', type=int, default=30, help='Keep data newer than N days') - 在
handle里通过options['days']取值，别直接用args - 布尔开关用
action='store_true'，例如--dry-run，对应options['dry_run']是 True/False - 参数名带下划线（
--keep-days）会在代码里转成keep_days，别手抖写错 key 名
容易踩的坑：type=int 但用户输了个字母，命令直接报错退出——这反而是好事，比静默失败强；如需容错，自己在 handle 里 try/except 并 print 友好提示。
定时执行时为什么日志没输出，或任务根本没跑
用系统 cron 或 systemd 跑 Django 命令，最容易出问题的地方不是代码，而是环境没对齐。
实操建议：
- 绝对路径启动：cron 里写
/usr/local/bin/python3 /path/to/myproject/manage.py clean_old_logs --days 60，别用cd && python manage.py - 显式指定
DJANGO_SETTINGS_MODULE：cron 行开头加DJANGO_SETTINGS_MODULE=myproject.settings.production - 重定向 stdout/stderr：加
> /var/log/django-clean.log 2>&1，否则看不到报错 - 检查用户权限：运行 cron 的用户（如
www-data）是否对项目目录、数据库 socket、日志路径有读写权限
兼容性影响：不同 shell 对 ~ 符号、环境变量继承策略不同，所以别依赖 ~/.bashrc 里的 PYTHONPATH 或 virtualenv activate；用绝对路径 + 显式 source venv/bin/activate 更稳（但更推荐直接调用 venv 里的 python 解释器）。
最常被忽略的一点：Django 的数据库连接在命令结束后才关闭，如果清理过程太久（比如几十分钟），中间数据库连接超时或被 kill，后续操作就全挂了——得在循环里手动 connection.close() 或用 transaction.atomic() 分段控制。
