因为Django默认在Command.handle()中启用完整请求上下文和信号监听，ORM操作会触发预加载、字段验证及pre_save/post_save信号，大幅增加开销。
为什么 handle() 里写 ORM 查询会变慢？
因为 Django 默认在每次 Command.handle() 执行时都启用完整请求上下文和信号监听，哪怕你只是跑个后台任务。大量 Model.objects.filter() 或 save() 触发的 pre_save/post_save 信号、字段验证、关系预加载，都会悄悄拖慢命令执行速度。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在
handle()开头加from django.db import transaction，用transaction.atomic()包裹批量写入，避免每条save()都提交事务 - 禁用非必要信号：临时断开
post_save等，例如post_save.disconnect(sender=MyModel)（记得结束后 reconnect） - 查数据时显式用
.values_list('id', 'name')或.only('id', 'name')，避免加载整个 model 实例和未使用字段 - 避免在循环里调用
model_instance.save()，改用Model.objects.bulk_create()或bulk_update()
如何让 Management Command 支持分页处理百万级数据？
直接 Model.objects.all() 加 for 循环会把全部记录加载进内存，OOM 是大概率事件。关键不是“怎么遍历”，而是“怎么不一次性加载”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用主键 ID 分段：先
min_id = Model.objects.order_by('id').values_list('id', flat=True).first()，再while min_id is not None:+Model.objects.filter(id__range=(min_id, min_id + 999)).order_by('id') - 配合
iterator(chunk_size=2000)：它不会缓存 QuerySet，但注意仍需搭配.values()或.only()使用才真正省内存 - 别依赖
.count()做总页数——MySQL 上它可能触发全表扫描；用估算或分段推进更可靠 - 加日志记录当前处理 ID 范围，方便中断后从断点续跑，例如写入一个临时
last_processed_id文件或数据库配置表
BaseCommand 的 requires_system_checks 和 output_transaction 怎么选？
这两个参数不常被注意，但直接影响启动耗时和输出可读性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
requires_system_checks = False：适合已知环境稳定的运维脚本（如定时清理），跳过 Django 启动时的数据库连接、URL 配置等检查，能快 100–300ms -
output_transaction = True：仅当命令本身是 SQL 导出类操作（比如dumpdata衍生命令）才设为True，它会让输出包含 BEGIN/COMMIT 包裹，否则保持默认False - 如果命令要读写多个数据库，务必在
handle()中显式指定using='other_db'，别依赖DEFAULT_DB_ALIAS，否则容易连错库还查不到错误
本地调试时为什么 python manage.py mycmd 报 django.core.exceptions.AppRegistryNotReady？
这不是代码问题，而是 Django 应用注册时机不对。常见于把命令逻辑提前 import 到模块顶层，或在 __init__.py 里触发了 model 导入。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有 model 导入必须放在
handle()函数内部，或至少放在if __name__ == '__main__':下（虽然 Management Command 不走这个分支，但能提醒自己） - 不要在 command 文件顶部写
from myapp.models import MyModel，改用MyModel = apps.get_model('myapp', 'MyModel')动态获取（需先from django.apps import apps） - 如果用了自定义装饰器或工具函数，确认它们没在 import 时就访问
Model._meta或Model.objects
性能优化的边界往往不在算法，而在你是否意识到 Django 的“默认行为”正在替你做一堆你并不需要的事。删掉一个信号、推迟一次 import、换一种查询方式，效果可能比加机器还明显。
