因为manage.py自动完成Django环境初始化（ORM、配置、数据库连接等），避免Settings导入错误；自定义命令需置于management/commands/下，继承BaseCommand并实现handle方法，参数须通过add_arguments显式注册，查询大数据集应使用iterator或bulk_update防止内存溢出。
为什么 manage.py 命令比直接运行 .py 脚本更可靠？
因为 Django 的 ORM、配置、数据库连接、信号、中间件等都在 manage.py 启动时完成初始化；直接用 python my_script.py 很可能报 DjangoRuntimeError: Settings cannot be imported 或查不到模型。自定义命令天然共享项目上下文，省去手动调用 django.setup() 和配置环境变量的麻烦。
实操建议：
- 命令必须放在应用目录下的
management/commands/子目录中（路径需完整：myapp/management/commands/mytask.py） -
mytask.py文件内必须定义一个继承BaseCommand的类，且类名不重要，但必须有handle(self, *args, **options)方法 - 文件名即命令名：
python manage.py mytask，不能含下划线或大写字母（Django 会忽略）
如何接收参数并避免 TypeError: handle() got an unexpected keyword argument？
参数必须通过 add_arguments(self, parser) 显式注册，不能靠 **options 直接解包——Django 不会自动把未声明的 flag 透传进 handle。
常见错误现象：加了 --dry-run 却在 handle 里直接写 if options['dry_run']:，结果报错。
立即学习“Python免费学习笔记（深入）”；
正确做法：
- 在
add_arguments中用parser.add_argument('--dry-run', action='store_true')注册布尔开关 - 用
type=int或type=str明确指定类型，避免字符串被误当整数用 - 必填参数加
required=True，否则options里对应键可能不存在（不是None，而是根本没这个 key）
示例片段：
def add_arguments(self, parser):
parser.add_argument('--limit', type=int, default=100)
parser.add_argument('--user-id', type=int, required=True)
parser.add_argument('--force', action='store_true')
为什么批量操作数据库时脚本卡住或内存爆掉？
默认 Django ORM 查询会把全部结果加载进内存，比如 User.objects.all() 处理 10 万用户，很可能 OOM。这不是命令本身的问题，而是没适配管理命令的执行场景。
性能关键点：
- 用
.iterator(chunk_size=2000)替代直接遍历 QuerySet（注意：它不支持切片、len()或重复迭代） - 大批量更新优先用
bulk_update()或原生 SQL（connection.cursor()），避免逐条save() - 涉及事务控制时，用
transaction.atomic()包裹，但别包裹整个循环——否则锁表时间过长 - 如果命令要长期运行（如监听队列），记得在循环中加
time.sleep(1)，防止 CPU 占满
如何调试命令却看不到 print() 实时输出？
不是代码没执行，而是 Python 缓冲机制 + Django 默认关闭 stdout 行缓冲。尤其在 CI 环境或重定向输出时，print("step 1") 可能一直不显示，直到命令结束才刷出全部日志。
解决方式很直接：
- 所有
print()加flush=True：print("processing...", flush=True) - 或者统一用
self.stdout.write("...")，它默认实时刷新，还能自动加换行 - 调试时加
--verbosity=2（如果命令支持），再配合self.stdout.write(..., style_func=self.style.SUCCESS)做分级输出
容易被忽略的是：生产环境跑定时任务时，如果依赖 print 查进度，大概率会误判脚本“卡死”。
