django-admin 和 manage.py — Django 文档

django-admin 和 manage.py

django-admin 是 Django 用于管理任务的命令行实用程序。 本文档概述了它可以做的所有事情。

另外，manage.py 是在每个 Django 项目中自动创建的。 它与 django-admin 执行相同的操作，但还设置了 DJANGO_SETTINGS_MODULE 环境变量，使其指向您项目的 settings.py 文件。

如果您通过 pip 安装了 Django，那么 django-admin 脚本应该在您的系统路径上。 如果它不在您的路径中，请确保您已激活虚拟环境。

通常，在处理单个 Django 项目时，使用 manage.py 比使用 django-admin 更容易。 如果您需要在多个 Django 设置文件之间切换，请使用 django-admin 和 DJANGO_SETTINGS_MODULE 或 --settings 命令行选项。

本文档中的命令行示例使用 django-admin 以保持一致，但任何示例也可以使用 manage.py 或 python -m django。

用法

command 应该是本文档中列出的命令之一。 options 是可选的，应该是零个或多个可用于给定命令的选项。

获取运行时帮助

运行 django-admin help 以显示使用信息和每个应用程序提供的命令列表。

运行 django-admin help --commands 以显示所有可用命令的列表。

运行 django-admin help <command> 以显示给定命令的描述及其可用选项列表。

应用名称

许多命令采用“应用程序名称”列表。 “应用程序名称”是包含模型的包的基本名称。 例如，如果您的 :setting:`INSTALLED_APPS` 包含字符串 'mysite.blog'，则应用名称为 blog。

确定版本

运行 django-admin version 以显示当前的 Django 版本。

输出遵循 PEP 440 中描述的架构：

1.4.dev17026
1.4a1
1.4

显示调试输出

使用 --verbosity 指定 django-admin 打印到控制台的通知和调试信息的数量。

可用命令

check

使用系统检查框架检查整个Django项目的常见问题。

默认情况下，将检查所有应用程序。 您可以通过提供应用标签列表作为参数来检查应用的子集：

django-admin check auth admin myapp

系统检查框架执行许多不同类型的检查，这些检查是 用标签 分类的。 您可以使用这些标签将执行的检查限制为仅针对特定类别中的检查。 例如，要仅执行模型和兼容性检查，请运行：

django-admin check --tag models --tag compatibility

3.1 版中的新功能。

指定要运行需要访问数据库的检查的数据库：

django-admin check --database default --database other

默认情况下，不会运行这些检查。

列出所有可用的标签。

激活一些仅与部署设置相关的附加检查。

您可以在本地开发环境中使用此选项，但由于您的本地开发设置模块可能没有许多生产设置，您可能希望将 check 命令指向不同的设置模块，通过设置DJANGO_SETTINGS_MODULE 环境变量，或通过传递 --settings 选项：

django-admin check --deploy --settings=production_settings

或者您可以直接在生产或临时部署上运行它以验证是否使用了正确的设置（省略 --settings）。 您甚至可以将其作为集成测试套件的一部分。

指定将导致命令以非零状态退出的消息级别。 默认值为 ERROR。

compilemessages

将 :djadmin:`makemessages` 创建的 .po 文件编译为 .mo 文件，以便与内置的 gettext 支持一起使用。 参见 国际化和本地化 。

指定要处理的语言环境。 如果未提供，则处理所有语言环境。

指定要从处理中排除的区域设置。 如果未提供，则不排除任何区域设置。

将 模糊翻译 包含到编译文件中。

用法示例：

django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

3.0 版中的新功能。

忽略与给定 glob 样式模式匹配的目录。 多次使用以忽略更多。

用法示例：

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

createcachetable

使用设置文件中的信息创建用于数据库缓存后端的缓存表。 有关更多信息，请参阅 Django 的缓存框架 。

指定将在其中创建缓存表的数据库。 默认为 default。

打印将在不实际运行的情况下运行的 SQL，因此您可以自定义它或使用迁移框架。

dbshell

为您的数据库引擎中指定的数据库引擎运行命令行客户端 ：设置：`引擎 ` 设置，使用您在 ：设置：`用户` , ：设置：`密码` 等，设置。

• 对于 PostgreSQL，它运行 psql 命令行客户端。
• 对于 MySQL，这将运行 mysql 命令行客户端。
• 对于 SQLite，它运行 sqlite3 命令行客户端。
• 对于 Oracle，这将运行 sqlplus 命令行客户端。

此命令假定程序在您的 PATH 上，以便调用程序名称 (psql、mysql、sqlite3、sqlplus ) 将在正确的位置找到该程序。 无法手动指定程序的位置。

指定要在其上打开 shell 的数据库。 默认为 default。

3.1 版中的新功能。

-- 分隔符后面的任何参数都将传递给底层命令行客户端。 例如，对于 PostgreSQL，您可以使用 psql 命令的 -c 标志直接执行原始 SQL 查询：

在 MySQL/MariaDB 上，您可以使用 mysql 命令的 -e 标志执行此操作：

笔记

请注意，并非所有在 :setting:`DATABASES` 中的数据库配置的 :setting:`OPTIONS` 部分中设置的选项都传递给命令行客户端，例如 'isolation_level'。

diffsettings

显示当前设置文件和 Django 的默认设置（或由 --default 指定的另一个设置文件）之间的差异。

默认值中没有出现的设置后面跟着"###"。 例如，默认设置没有定义 :setting:`ROOT_URLCONF`，所以 :setting:`ROOT_URLCONF` 在 "###" X159X]。

显示所有设置，即使它们具有 Django 的默认值。 此类设置以 "###" 为前缀。

用于比较当前设置的设置模块。 留空以与 Django 的默认设置进行比较。

指定输出格式。 可用值为 hash 和 unified。 hash 是显示上述输出的默认模式。 unified 显示类似于 diff -u 的输出。 默认设置以减号为前缀，后跟以加号为前缀的更改设置。

dumpdata

将数据库中与指定应用程序关联的所有数据输出到标准输出。

如果未提供应用程序名称，则将转储所有已安装的应用程序。

dumpdata 的输出可以用作 :djadmin:`loaddata` 的输入。

请注意，dumpdata 使用模型上的默认管理器来选择要转储的记录。 如果您使用 自定义管理器 作为默认管理器并且它过滤了一些可用记录，则并非所有对象都将被转储。

使用 Django 的基本管理器，转储可能会被自定义管理器过滤或修改的记录。

指定输出的序列化格式。 默认为 JSON。 支持的格式在序列化格式中列出。

指定要在输出中使用的缩进空格数。 默认为 None，在一行上显示所有数据。

防止转储特定的应用程序或模型（以 app_label.ModelName 的形式指定）。 如果您指定模型名称，则只会排除该模型，而不是整个应用程序。 您还可以混合应用程序名称和型号名称。

如果要排除多个应用程序，请多次传递 --exclude：

django-admin dumpdata --exclude=auth --exclude=contenttypes

指定将转储数据的数据库。 默认为 default。

使用 natural_key() 模型方法将任何外键和多对多关系序列化到定义该方法的类型的对象。 如果您要转储 contrib.auth Permission 对象或 contrib.contenttypes ContentType 对象，您可能应该使用此标志。 有关此选项和下一个选项的更多详细信息，请参阅 自然键 文档。

省略此对象的序列化数据中的主键，因为它可以在反序列化期间计算。

仅输出由逗号分隔的主键列表指定的对象。 这仅在倾销一种模型时可用。 默认输出模型的所有记录。

指定要写入序列化数据的文件。 默认情况下，数据进入标准输出。

当设置此选项且 --verbosity 大于 0（默认）时，终端中会显示进度条。

flush

从数据库中删除所有数据并重新执行任何同步后处理程序。 已应用迁移的表不会被清除。

如果您宁愿从空数据库开始并重新运行所有迁移，您应该删除并重新创建数据库，然后运行 :djadmin:`migrate`。

禁止所有用户提示。

指定要刷新的数据库。 默认为 default。

inspectdb

内省 :setting:`NAME` 设置指向的数据库中的数据库表，并将 Django 模型模块（models.py 文件）输出到标准输出。

您可以通过将名称作为参数传递来选择要检查的表或视图。 如果未提供参数，则仅在使用 --include-views 选项时才为视图创建模型。 如果使用 --include-partitions 选项，则在 PostgreSQL 上创建分区表模型。

如果您有一个要使用 Django 的旧数据库，请使用此选项。 该脚本将检查数据库并为其中的每个表创建一个模型。

正如您所料，创建的模型将具有表中每个字段的属性。 请注意， inspectdb 在其字段名输出中有一些特殊情况：

• 如果 inspectdb 无法将列的类型映射到模型字段类型，它将使用 TextField 并将在生成的模型中的字段旁边插入 Python 注释 'This field type is a guess.'。 识别的字段可能取决于 :setting:`INSTALLED_APPS` 中列出的应用程序。 例如，django.contrib.postgres 添加了对几种 PostgreSQL 特定字段类型的识别。
• 如果数据库列名是 Python 保留字（例如 'pass'、'class' 或 'for'），则 inspectdb 将附加 '_field'属性名称。 例如，如果一个表有一个列 'for'，生成的模型将有一个字段 'for_field'，db_column 属性设置为 'for'。 inspectdb 将在字段旁边插入 Python 注释 'Field renamed because it was a Python reserved word.'。

此功能是一种快捷方式，而不是确定的模型生成。 运行后，您需要自己查看生成的模型以进行自定义。 特别是，您需要重新排列模型的顺序，以便正确排列引用其他模型的模型。

当在模型字段上指定 default 时，Django 不会创建数据库默认值。 同样，数据库默认值不会转换为模型字段默认值，也不会被 inspectdb 以任何方式检测到。

默认情况下，inspectdb 创建非托管模型。 也就是说，模型的 Meta 类中的 managed = False 告诉 Django 不要管理每个表的创建、修改和删除。 如果您确实想让 Django 管理表的生命周期，则需要将 managed 选项更改为 True（或删除它，因为 True 是其默认值）。

特定于数据库的注释

甲骨文

• 如果使用 --include-views，则为实体化视图创建模型。

PostgreSQL

• 模型是为外部表创建的。
• 如果使用 --include-views，则为实体化视图创建模型。
• 如果使用 --include-partitions，则为分区表创建模型。

指定要内省的数据库。 默认为 default。

如果提供此选项，还会为分区创建模型。

仅实现了对 PostgreSQL 的支持。

如果提供此选项，还会为数据库视图创建模型。

loaddata

搜索命名装置的内容并将其加载到数据库中。

指定数据将加载到的数据库。 默认为 default。

忽略自最初生成夹具以来可能已删除的字段和模型。

指定要在其中查找设备的单个应用程序，而不是在所有应用程序中查找。

为从 stdin 读取的装置 指定 序列化格式 （例如，json 或 xml）。

不包括从给定的应用程序和/或模型（以 app_label 或 app_label.ModelName 的形式）加载灯具。 多次使用该选项以排除多个应用程序或模型。

什么是“夹具”？

fixture 是包含数据库序列化内容的文件集合。 每个夹具都有一个唯一的名称，构成夹具的文件可以分布在多个目录、多个应用程序中。

Django 将在三个位置搜索设备：

1. 在每个已安装应用程序的 fixtures 目录中
2. 在 :setting:`FIXTURE_DIRS` 设置中命名的任何目录中
3. 在夹具命名的文字路径中

Django 将加载它在这些位置找到的与提供的设备名称匹配的所有设备。

如果命名装置具有文件扩展名，则只会加载该类型的装置。 例如：

django-admin loaddata mydata.json

只会加载名为 mydata 的 JSON 固定装置。 夹具扩展名必须对应于 串行器 的注册名称（例如，json 或 xml）。

如果省略扩展名，Django 将搜索所有可用的设备类型以查找匹配的设备。 例如：

django-admin loaddata mydata

将寻找任何名为 mydata 的夹具类型的任何夹具。 如果夹具目录包含 mydata.json，则该夹具将作为 JSON 夹具加载。

命名的装置可以包含目录组件。 这些目录将包含在搜索路径中。 例如：

django-admin loaddata foo/bar/mydata.json

将为每个已安装的应用程序搜索 <app_label>/fixtures/foo/bar/mydata.json，为 :setting:`FIXTURE_DIRS` 中的每个目录搜索 <dirname>/foo/bar/mydata.json，以及文字路径 foo/bar/mydata.json。

处理夹具文件时，数据按原样保存到数据库中。 模型定义的 save() 方法不会被调用，并且任何 pre_save 或 post_save 信号将使用 raw=True 调用，因为实例只包含属性是模型本地的。 例如，您可能想要禁用访问在夹具加载期间不存在的相关字段的处理程序，否则会引发异常：

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

您还可以编写一个装饰器来封装此逻辑：

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

@disable_for_loaddata
def my_handler(**kwargs):
    ...

请注意，此逻辑将在灯具反序列化时禁用信号，而不仅仅是在 loaddata 期间。

请注意，夹具文件的处理顺序是未定义的。 但是，所有夹具数据都作为单个事务安装，因此一个夹具中的数据可以引用另一个夹具中的数据。 如果数据库后端支持行级约束，则会在事务结束时检查这些约束。

:djadmin:`dumpdata` 命令可用于为 loaddata 生成输入。

压缩夹具

灯具可以压缩为 zip、gz 或 bz2 格式。 例如：

django-admin loaddata mydata.json

将查找 mydata.json、mydata.json.zip、mydata.json.gz 或 mydata.json.bz2 中的任何一个。 使用 zip 压缩存档中包含的第一个文件。

请注意，如果发现两个同名但灯具类型不同的灯具（例如，如果在同一灯具目录中发现 mydata.json 和 mydata.xml.gz），则灯具安装将被中止，并且任何在调用 loaddata 时安装的数据将从数据库中删除。

带有 MyISAM 和装置的 MySQL

MySQL 的 MyISAM 存储引擎不支持事务或约束，因此如果您使用 MyISAM，您将不会得到夹具数据的验证，或者如果找到多个事务文件则回滚。

特定于数据库的装置

如果您处于多数据库设置中，您可能希望将夹具数据加载到一个数据库中，但不想加载到另一个数据库中。 在这种情况下，您可以将数据库标识符添加到灯具的名称中。

例如，如果您的 :setting:`DATABASES` 设置定义了一个“主”数据库，则将夹具命名为 mydata.master.json 或 mydata.master.json.gz，并且夹具将仅在您指定要将数据加载到 master 数据库中。

从 stdin 加载夹具

您可以使用破折号作为灯具名称来加载来自 sys.stdin 的输入。 例如：

django-admin loaddata --format=json -

从stdin读取时，需要--format选项来指定输入的序列化格式（例如，json或xml ）。

从 stdin 加载对于标准输入和输出重定向很有用。 例如：

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

makemessages

遍历当前目录的整个源代码树并提取所有标记为翻译的字符串。 它在 conf/locale（在 Django 树中）或 locale（用于项目和应用程序）目录中创建（或更新）一个消息文件。 对消息文件进行更改后，您需要使用 :djadmin:`compilemessages` 编译它们，以便与内置的 gettext 支持一起使用。 有关详细信息，请参阅 i18n 文档 。

此命令不需要配置设置。 但是，当没有配置设置时，该命令不能忽略 :setting:`MEDIA_ROOT` 和 :setting:`STATIC_ROOT` 目录或包含 :setting： `LOCALE_PATHS`。

更新所有可用语言的消息文件。

指定要检查的文件扩展名列表（默认值：html、txt、py 或 js 如果 --domain 是 [ X122X]）。

用法示例：

django-admin makemessages --locale=de --extension xhtml

用逗号分隔多个扩展名或多次使用 -e 或 --extension：

django-admin makemessages --locale=de --extension=html,txt --extension xml

指定要处理的语言环境。

指定要从处理中排除的区域设置。 如果未提供，则不排除任何区域设置。

用法示例：

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

指定消息文件的域。 支持的选项有：

• django 适用于所有 *.py、*.html 和 *.txt 文件（默认）
• djangojs 用于 *.js 文件

在查找新的翻译字符串时遵循指向目录的符号链接。

用法示例：

django-admin makemessages --locale=de --symlinks

忽略与给定 glob 样式模式匹配的文件或目录。 多次使用以忽略更多。

默认使用这些模式：'CVS'、'.*'、'*~'、'*.pyc'。

用法示例：

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

禁用 --ignore 的默认值。

禁止将长消息行拆分为语言文件中的多行。

禁止在语言文件中写入“#: filename:line”注释行。 使用此选项会使技术熟练的翻译人员更难理解每条消息的上下文。

控制语言文件中的 #: filename:line 注释行。 如果选项是：

• full（如果没有给出默认值）：行包括文件名和行号。
• file：行号省略。
• never：行被抑制（同--no-location）。

需要 gettext 0.19 或更新版本。

防止删除在创建 .po 文件之前生成的临时 .pot 文件。 这对于调试可能阻止创建最终语言文件的错误很有用。

也可以看看

有关如何自定义 :djadmin:`makemessages` 传递给 xgettext 的关键字的说明，请参阅 自定义 makemessages 命令 。

makemigrations

根据检测到的模型更改创建新迁移。 迁移文档 中详细介绍了迁移及其与应用程序的关系等。

提供一个或多个应用程序名称作为参数将限制为指定的应用程序创建的迁移以及所需的任何依赖项（例如 ForeignKey 另一端的表）。

要将迁移添加到没有 migrations 目录的应用程序，请使用应用程序的 app_label 运行 makemigrations。

禁止所有用户提示。 如果无法自动解决被抑制的提示，该命令将退出并显示错误代码 3。

输出指定应用程序的空迁移，以进行手动编辑。 这适用于高级用户，除非您熟悉迁移格式、迁移操作以及迁移之间的依赖关系，否则不应使用。

显示将在不实际将任何迁移文件写入磁盘的情况下进行的迁移。 将此选项与 --verbosity 3 一起使用还将显示将写入的完整迁移文件。

启用修复迁移冲突。

允许命名生成的迁移而不是使用生成的名称。 名称必须是有效的 Python 标识符 。

生成没有 Django 版本和时间戳标头的迁移文件。

当检测到没有迁移的模型更改时，使 makemigrations 以非零状态退出。

migrate

将数据库状态与当前的模型和迁移集同步。 迁移文档 中详细介绍了迁移及其与应用程序的关系等。

此命令的行为根据提供的参数而变化：

• 无参数：所有应用程序都运行了所有迁移。
• <app_label>：指定的应用程序运行其迁移，直到最近的迁移。 由于依赖关系，这也可能涉及运行其他应用程序的迁移。
• <app_label> <migrationname>：将数据库架构带到应用命名迁移的状态，但不会应用同一应用程序中的后续迁移。 如果您之前迁移过指定迁移，则这可能涉及取消应用迁移。 您可以使用迁移名称的前缀，例如 0001，只要它对于给定的应用程序名称是唯一的。 使用名称 zero 一路迁移回来即 恢复应用程序的所有应用迁移。

警告

取消应用迁移时，所有依赖的迁移也将取消应用，无论 <app_label>。 您可以使用 --plan 来检查哪些迁移将不被应用。

指定要迁移的数据库。 默认为 default。

将向目标迁移（遵循上述规则）标记为已应用，但不实际运行 SQL 来更改数据库架构。

这适用于高级用户在手动应用更改时直接操作当前迁移状态； 请注意，使用 --fake 存在将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险。

如果在该迁移中的所有 CreateModel 操作创建的具有所有模型名称的所有数据库表已经存在，则允许 Django 跳过应用程序的初始迁移。 此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用。 但是，此选项不会检查匹配表名称之外的匹配数据库架构，因此只有在您确信现有架构与初始迁移中记录的架构匹配时才可以安全使用。

显示将为给定的 migrate 命令执行的迁移操作。

允许为应用程序创建表而无需迁移。 虽然不建议这样做，但迁移框架有时在具有数百个模型的大型项目上太慢。

禁止所有用户提示。 一个示例提示是询问删除陈旧的内容类型。

3.1 版中的新功能。

当检测到未应用的迁移时，使 migrate 以非零状态退出。

runserver

在本地机器上启动轻量级开发 Web 服务器。 默认情况下，服务器在 IP 地址 127.0.0.1 上的端口 8000 上运行。 您可以明确传入 IP 地址和端口号。

如果您以具有普通权限（推荐）的用户身份运行此脚本，您可能无权在低端口号上启动端口。 为超级用户 (root) 保留低端口号。

此服务器使用由 :setting:`WSGI_APPLICATION` 设置指定的 WSGI 应用程序对象。

请勿在生产环境中使用此服务器。 它没有经过安全审计或性能测试。 （这就是它会留下来的方式。 我们的工作是制作 Web 框架，而不是 Web 服务器，因此改进此服务器以处理生产环境超出了 Django 的范围。）

开发服务器根据需要自动为每个请求重新加载 Python 代码。 您无需重新启动服务器即可使代码更改生效。 但是，某些操作（例如添加文件）不会触发重新启动，因此在这些情况下您必须重新启动服务器。

如果您使用 Linux 或 MacOS 并安装 pywatchman 和 Watchman 服务，内核信号将用于自动重新加载服务器（而不是每秒轮询文件修改时间戳）。 这为大型项目提供了更好的性能、缩短了代码更改后的响应时间、更强大的更改检测并降低了功耗。 Django 支持 pywatchman 1.2.0 及更高版本。

包含许多文件的大目录可能会导致性能问题

将 Watchman 用于包含大型非 Python 目录（如 node_modules）的项目时，建议忽略此目录以获得最佳性能。 有关如何执行此操作的信息，请参阅 watchman 文档 。

守望者超时

DJANGO_WATCHMAN_TIMEOUT

Watchman 客户端的默认超时时间为 5 秒。 您可以通过设置 DJANGO_WATCHMAN_TIMEOUT 环境变量来更改它。

当您启动服务器时，每次在服务器运行时更改 Python 代码时，系统检查框架都会检查您的整个 Django 项目是否存在一些常见错误（请参阅 :djadmin:`check` 命令） . 如果发现任何错误，它们将打印到标准输出。

您可以根据需要运行任意数量的并发服务器，只要它们通过多次执行 django-admin runserver 位于不同的端口上即可。

请注意，网络上的其他机器无法访问默认 IP 地址 127.0.0.1。 要使网络上的其他机器可以查看您的开发服务器，请使用其自己的 IP 地址（例如 192.168.2.1) 或 0.0.0.0 或 ::（启用 IPv6）。

您可以提供一个用括号括起来的 IPv6 地址（例如 [200a::1]:8000）。 这将自动启用 IPv6 支持。

也可以使用仅包含 ASCII 字符的主机名。

如果启用了 staticfiles contrib 应用程序（新项目中的默认设置），则 :djadmin:`runserver` 命令将被其自己的 runserver 命令覆盖。

服务器的每个请求和响应的日志发送到 django.server 记录器。

禁用自动重新加载器。 这意味着您在服务器运行时所做的任何 Python 代码更改将 不会 生效，如果特定的 Python 模块已经加载到内存中。

在开发服务器中禁用线程。 服务器默认是多线程的。

对开发服务器使用 IPv6。 这会将默认 IP 地址从 127.0.0.1 更改为 ::1。

使用不同端口和地址的示例

IP 地址 127.0.0.1 上的端口 8000：

django-admin runserver

IP 地址 1.2.3.4 上的端口 8000：

django-admin runserver 1.2.3.4:8000

IP 地址 127.0.0.1 上的端口 7000：

django-admin runserver 7000

IP 地址 1.2.3.4 上的端口 7000：

django-admin runserver 1.2.3.4:7000

IPv6 地址 ::1 上的端口 8000：

django-admin runserver -6

IPv6 地址 ::1 上的端口 7000：

django-admin runserver -6 7000

IPv6 地址 2001:0db8:1234:5678::9 上的端口 7000：

django-admin runserver [2001:0db8:1234:5678::9]:7000

主机 localhost 的 IPv4 地址上的端口 8000：

django-admin runserver localhost:8000

主机 localhost 的 IPv6 地址上的端口 8000：

django-admin runserver -6 localhost:8000

使用开发服务器提供静态文件

默认情况下，开发服务器不会为您的站点提供任何静态文件（例如 CSS 文件、图像、:setting:`MEDIA_URL` 下的内容等）。 如果要配置 Django 以提供静态媒体服务，请阅读管理静态文件（例如 图片、JavaScript、CSS） .

sendtestemail

向指定的收件人发送测试电子邮件（以确认通过 Django 发送的电子邮件正在工作）。 例如：

django-admin sendtestemail foo@example.com bar@example.com

有几个选项，您可以将它们任意组合使用：

使用 mail_managers() 邮寄 :setting:`MANAGERS` 中指定的电子邮件地址。

使用 mail_admins() 邮寄 :setting:`ADMINS` 中指定的电子邮件地址。

shell

启动 Python 交互式解释器。

指定要使用的外壳。 默认情况下，如果安装了 IPython 或 bpython，Django 将使用。 如果两者都安装了，请指定您想要的那个：

蟒蛇：

django-admin shell -i ipython

蟒蛇：

django-admin shell -i bpython

如果您安装了“丰富的”shell，但想强制使用“普通”的 Python 解释器，请使用 python 作为接口名称，如下所示：

django-admin shell -i python

禁止读取“普通”Python 解释器的启动脚本。 默认情况下，读取 PYTHONSTARTUP 环境变量或 ~/.pythonrc.py 脚本指向的脚本。

允许您将命令作为字符串传递以作为 Django 执行它，如下所示：

django-admin shell --command="import django; print(django.__version__)"

您还可以在标准输入上传递代码以执行它。 例如：

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

在 Windows 上，由于该平台上 select.select() 的实现限制，会输出 REPL。

showmigrations

显示项目中的所有迁移。 您可以选择以下两种格式之一：

列出 Django 知道的所有应用程序、每个应用程序可用的迁移以及是否应用了每个迁移（由迁移名称旁边的 [X] 标记）。 对于 2 及以上的 --verbosity，还会显示应用的日期时间。

还列出了没有迁移的应用程序，但在它们下面印有 (no migrations)。

这是默认的输出格式。

在 3.0 版中更改：添加了详细程度 2 及以上的应用日期时间的输出。

显示 Django 将遵循的迁移计划来应用迁移。 与 --list 一样，已应用的迁移由 [X] 标记。 对于 2 及以上的 --verbosity，还将显示迁移的所有依赖项。

app_label 的参数限制了输出，但是，也可能包含提供的应用程序的依赖项。

指定要检查的数据库。 默认为 default。

sqlflush

打印将为 :djadmin:`flush` 命令执行的 SQL 语句。

指定要为其打印 SQL 的数据库。 默认为 default。

sqlmigrate

打印指定迁移的 SQL。 这需要一个活动的数据库连接，它将用于解析约束名称； 这意味着您必须针对您希望稍后应用的数据库副本生成 SQL。

请注意， sqlmigrate 不会为其输出着色。

生成用于取消应用迁移的 SQL。 默认情况下，创建的 SQL 用于运行正向迁移。

指定要为其生成 SQL 的数据库。 默认为 default。

sqlsequencereset

打印用于重置给定应用程序名称序列的 SQL 语句。

序列是某些数据库引擎用于跟踪自动递增字段的下一个可用数字的索引。

使用此命令生成 SQL，该 SQL 将修复序列与其自动增加的字段数据不同步的情况。

指定要为其打印 SQL 的数据库。 默认为 default。

squashmigrations

如果可能，将 app_label 上至并包括 migration_name 的迁移压缩为更少的迁移。 由此产生的被压扁的迁移可以安全地与未被压扁的迁移一起生活。 有关更多信息，请阅读 压缩迁移 。

当给出 start_migration_name 时，Django 将只包含从此迁移开始并包含此迁移的迁移。 这有助于减轻 RunPython 和 django.db.migrations.operations.RunSQL 迁移操作的压缩限制。

在生成压缩迁移时禁用优化器。 默认情况下，Django 会尝试优化迁移中的操作以减小结果文件的大小。 如果此过程失败或创建不正确的迁移，请使用此选项，但也请提交有关该行为的 Django 错误报告，因为优化是安全的。

禁止所有用户提示。

设置压缩迁移的名称。 省略时，名称基于第一次和最后一次迁移，中间有 _squashed_。

生成没有 Django 版本和时间戳标头的压缩迁移文件。

startapp

为当前目录或给定目标中的给定应用程序名称创建 Django 应用程序目录结构。

默认情况下， :source:`新目录 ` 包含一个models.py文件和其他应用程序模板文件。 如果只给出了应用程序名称，应用程序目录将在当前工作目录中创建。

如果提供了可选目标，Django 将使用现有目录而不是创建一个新目录。 您可以使用 '。' 表示当前工作目录。

例如：

django-admin startapp myapp /Users/jezdez/Code/myapp

提供自定义应用程序模板文件的目录路径，或未压缩存档 (.tar) 或压缩存档 (.tar.gz、.tar.bz2、.tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip 包含模板文件。

例如，这将在创建 myapp 应用程序时在给定目录中查找应用程序模板：

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django 还将接受 URL（http、https、ftp）到带有应用程序模板文件的压缩档案，即时下载和提取它们。

例如，利用 GitHub 的功能将存储库公开为 zip 文件，您可以使用如下 URL：

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp

在 3.0 版更改：添加了对 XZ 档案（.tar.xz、.txz）和 LZMA 档案（.tar.lzma、.tlz）的支持.

指定应使用模板引擎呈现应用模板中的哪些文件扩展名。 默认为 py。

指定应使用模板引擎呈现应用模板中的哪些文件（除了那些匹配的 --extension）。 默认为空列表。

用于所有匹配文件的 模板上下文 是：

• 传递给 startapp 命令的任何选项（在命令支持的选项中）
• app_name – 传递给命令的应用程序名称
• app_directory – 新创建的应用程序的完整路径
• camel_case_app_name – 驼峰格式的应用名称
• docs_version – 文档版本：'dev' 或 '1.x'
• django_version – Django 的版本，例如 '2.0.3'

警告

当应用模板文件使用 Django 模板引擎（默认所有 *.py 文件）呈现时，Django 也会替换包含的所有杂散模板变量。 例如，如果其中一个 Python 文件包含解释与模板渲染相关的特定功能的文档字符串，则可能会导致示例不正确。

要解决此问题，您可以使用 :ttag:`templatetag` 模板标签来“转义”模板语法的各个部分。

此外，为了允许包含 Django 模板语言语法的 Python 模板文件同时防止打包系统尝试字节编译无效的 *.py 文件，以 .py-tpl 结尾的模板文件将重命名为 .py。

startproject

为当前目录或给定目标中的给定项目名称创建 Django 项目目录结构。

默认情况下， :source:`新目录 ` 包含manage.py和一个项目包（包含一个settings.py和其他文件）。

如果只给出项目名称，项目目录和项目包都将命名为<projectname>，项目目录将在当前工作目录中创建。

如果提供了可选目标，Django 将使用该现有目录作为项目目录，并在其中创建 manage.py 和项目包。 用 '。' 表示当前工作目录。

例如：

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

指定自定义项目模板的目录、文件路径或 URL。 有关示例和用法，请参阅 startapp --template 文档。

指定应使用模板引擎呈现项目模板中的哪些文件扩展名。 默认为 py。

指定应使用模板引擎呈现项目模板中的哪些文件（除了那些匹配的 --extension）。 默认为空列表。

使用的 模板上下文 是：

• 传递给 startproject 命令的任何选项（在命令支持的选项中）
• project_name – 传递给命令的项目名称
• project_directory – 新建项目的完整路径
• secret_key – :setting:`SECRET_KEY` 设置的随机密钥
• docs_version – 文档版本：'dev' 或 '1.x'
• django_version – Django 的版本，例如 '2.0.3'

另请参阅 :djadmin:`startapp` 中提到的 渲染警告 。

test

对所有已安装的应用程序运行测试。 有关更多信息，请参阅 在 Django 中进行测试 。

停止运行测试并在测试失败后立即报告失败。

控制用于执行测试的测试运行器类。 此值覆盖 :setting:`TEST_RUNNER` 设置提供的值。

禁止所有用户提示。 典型的提示是关于删除现有测试数据库的警告。

测试运行器选项

test 命令代表指定的 --testrunner 接收选项。 这些是默认测试运行器的选项：DiscoverRunner。

在测试运行之间保留测试数据库。 这具有跳过创建和销毁操作的优点，这可以大大减少运行测试的时间，尤其是在大型测试套件中的测试。 如果测试数据库不存在，它将在第一次运行时创建，然后为每次后续运行保留。 除非 ：设置：`迁移 ` 测试设置是False ，在运行测试套件之前，任何未应用的迁移也将应用于测试数据库。

以相反的执行顺序对测试用例进行排序。 这可能有助于调试未正确隔离的测试的副作用。 使用该选项时，按测试类分组 被保留。

在运行测试之前将 :setting:`DEBUG` 设置设置为 True。 这可能有助于对测试失败进行故障排除。

为失败的测试启用 SQL 日志记录 。 如果 --verbosity 为 2，则还会输出通过测试的查询。

DJANGO_TEST_PROCESSES

在单独的并行进程中运行测试。 由于现代处理器具有多个内核，因此可以显着加快测试运行速度。

默认情况下，--parallel 根据 multiprocessing.cpu_count() 每个内核运行一个进程。 您可以通过提供它作为选项的值来调整进程数，例如 --parallel=4，或通过设置 DJANGO_TEST_PROCESSES 环境变量。

Django 将测试用例——unittest.TestCase 子类——分发到子进程。 如果测试用例比配置的进程少，Django 会相应地减少进程数。

每个进程都有自己的数据库。 您必须确保不同的测试用例不会访问相同的资源。 例如，接触文件系统的测试用例应该创建一个临时目录供他们自己使用。

笔记

如果您有无法并行运行的测试类，您可以使用 SerializeMixin 顺序运行它们。 请参阅 强制按顺序运行测试类 。

此选项需要第三方 tblib 包才能正确显示回溯：

$ python -m pip install tblib

此功能在 Windows 上不可用。 它也不适用于 Oracle 数据库后端。

如果要在调试测试时使用 pdb，则必须禁用并行执行 (--parallel=1)。 如果你不这样做，你会看到类似 bdb.BdbQuit 的东西。

警告

当启用测试并行化并且测试失败时，Django 可能无法显示异常回溯。 这会使调试变得困难。 如果遇到此问题，请在没有并行化的情况下运行受影响的测试以查看失败的回溯。

这是一个已知的限制。 它源于需要序列化对象以便在进程之间交换它们。 详见 python:pickle-picklable。

--tag TAGS

仅运行标有指定标签 的测试 。 可以多次指定并与 test --exclude-tag 结合使用。

--exclude-tag EXCLUDE_TAGS

排除用指定标签标记的测试。 可以多次指定并与 test --tag 结合使用。

3.0 版中的新功能。

以与 unittest's -k option 相同的方式运行与测试名称模式匹配的测试方法和类。 可以多次指定。

Python 3.7 及更高版本

此功能仅适用于 Python 3.7 及更高版本。

3.0 版中的新功能。

在每个测试错误或失败时产生一个 pdb 调试器。 如果已安装，则使用 ipdb 代替。

3.1 版中的新功能。

丢弃通过测试的输出（stdout 和 stderr），与 unittest's --buffer option 的方式相同。

testserver

使用来自给定装置的数据运行 Django 开发服务器（如 :djadmin:`runserver`）。

例如，这个命令：

django-admin testserver mydata.json

...将执行以下步骤：

1. 创建一个测试数据库，如测试数据库中所述。
2. 使用来自给定夹具的夹具数据填充测试数据库。 （有关装置的更多信息，请参阅上面的 :djadmin:`loaddata` 文档。）
3. 运行 Django 开发服务器（如 :djadmin:`runserver`），指向这个新创建的测试数据库而不是你的生产数据库。

这在很多方面都很有用：

• 当您编写 单元测试 以了解您的视图如何处理某些夹具数据时，您可以手动使用 testserver 与 Web 浏览器中的视图交互。
• 假设您正在开发您的 Django 应用程序，并且拥有您想要与之交互的数据库的“原始”副本。 您可以将数据库转储到夹具（使用 :djadmin:`dumpdata` 命令，如上所述），然后使用 testserver 使用该数据运行 Web 应用程序。 通过这种安排，您可以灵活地以任何方式弄乱您的数据，因为您知道所做的任何数据更改都只会对测试数据库进行。

请注意，此服务器 不会 自动检测 Python 源代码的更改（如 :djadmin:`runserver` 所做的那样）。 但是，它确实会检测对模板的更改。

指定与默认值 127.0.0.1:8000 不同的端口或 IP 地址和端口。 该值遵循与 :djadmin:`runserver` 命令的参数完全相同的格式并提供完全相同的功能。

例子：

使用 fixture1 和 fixture2 在端口 7000 上运行测试服务器：

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

（以上陈述是等价的。 我们将它们都包括在内，以证明选项是在夹具参数之前还是之后都无关紧要。）

使用 test 夹具在 1.2.3.4:7000 上运行：

django-admin testserver --addrport 1.2.3.4:7000 test

禁止所有用户提示。 典型的提示是关于删除现有测试数据库的警告。

应用程序提供的命令

某些命令仅在django.contrib应用程序工具他们已经 ：设置：`启用 ` . 本节按应用对它们进行分组。

django.contrib.auth

changepassword

此命令仅在安装了 Django 的 身份验证系统 (django.contrib.auth) 时可用。

允许更改用户的密码。 它会提示您为给定用户输入两次新密码。 如果条目相同，这将立即成为新密码。 如果您不提供用户，该命令将尝试更改用户名与当前用户匹配的密码。

指定要为用户查询的数据库。 默认为 default。

用法示例：

django-admin changepassword ringo

createsuperuser

DJANGO_SUPERUSER_PASSWORD

此命令仅在安装了 Django 的 身份验证系统 (django.contrib.auth) 时可用。

创建超级用户帐户（拥有所有权限的用户）。 如果您需要创建初始超级用户帐户或需要以编程方式为您的站点生成超级用户帐户，这将非常有用。

以交互方式运行时，此命令将提示输入新超级用户帐户的密码。 当以非交互方式运行时，您可以通过设置 DJANGO_SUPERUSER_PASSWORD 环境变量来提供密码。 否则，将不会设置密码，并且在手动为其设置密码之前，超级用户帐户将无法登录。

在非交互模式下，USERNAME_FIELD 和必填字段（在 REQUIRED_FIELDS 中列出）回退到 DJANGO_SUPERUSER_<uppercase_field_name> 环境变量，除非它们被命令行参数覆盖。 例如，要提供 email 字段，您可以使用 DJANGO_SUPERUSER_EMAIL 环境变量。

3.0 版更改： 添加了对使用 DJANGO_SUPERUSER_PASSWORD 和 DJANGO_SUPERUSER_<uppercase_field_name> 环境变量的支持。

禁止所有用户提示。 如果无法自动解决被抑制的提示，该命令将以错误代码 1 退出。

可以使用命令行上的 --username 和 --email 参数提供新帐户的用户名和电子邮件地址。 如果未提供其中任何一个，createsuperuser 将在交互运行时提示输入。

指定将保存超级用户对象的数据库。

如果您想自定义数据输入和验证，您可以子类化管理命令并覆盖 get_input_data()。 有关现有实现和方法参数的详细信息，请参阅源代码。 例如，如果您在 REQUIRED_FIELDS 中有一个 ForeignKey 并且希望允许创建实例而不是输入现有实例的主键，则它可能很有用。

django.contrib.contenttypes

remove_stale_contenttypes

此命令仅在安装了 Django 的 contenttypes app (django.contrib.contenttypes) 时可用。

删除数据库中过时的内容类型（从已删除的模型中）。 任何依赖于已删除内容类型的对象也将被删除。 在您确认可以继续删除之前，将显示已删除对象的列表。

指定要使用的数据库。 默认为 default。

3.1 版中的新功能。

删除陈旧的内容类型，包括来自已从 :setting:`INSTALLED_APPS` 中删除的以前安装的应用程序中的内容类型。 默认为 False。

django.contrib.gis

ogrinspect

此命令仅在安装了 GeoDjango (django.contrib.gis) 时可用。

请参考其 :djadmin:`说明 ` 在 GeoDjango 文档中。

django.contrib.sessions

clearsessions

可以作为 cron 作业运行或直接清除过期的会话。

django.contrib.sitemaps

ping_google

此命令仅在安装了 站点地图框架 (django.contrib.sitemaps) 时可用。

请参考其 :djadmin:`说明 ` 在站点地图文档中。

django.contrib.staticfiles

collectstatic

此命令仅在安装了 静态文件应用程序 (django.contrib.staticfiles) 时可用。

请参考其 :djadmin:`说明 ` 在里面静态文件文档。

findstatic

此命令仅在安装了 静态文件应用程序 (django.contrib.staticfiles) 时可用。

请参考其 :djadmin:`说明 ` 在里面静态文件文档。

默认选项

尽管某些命令可能允许它们自己的自定义选项，但每个命令都允许以下选项：

将给定的文件系统路径添加到 Python 导入搜索路径 。 如果未提供，django-admin 将使用 PYTHONPATH 环境变量。

这个选项在 manage.py 中是不必要的，因为它负责为你设置 Python 路径。

用法示例：

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

指定要使用的设置模块。 设置模块应该采用 Python 包语法，例如 mysite.settings。 如果没有提供，django-admin 将使用 DJANGO_SETTINGS_MODULE 环境变量。

在 manage.py 中不需要此选项，因为它默认使用当前项目中的 settings.py。

用法示例：

django-admin migrate --settings=mysite.settings

引发 CommandError 时显示完整的堆栈跟踪。 默认情况下，django-admin 将在发生 CommandError 时显示错误消息以及任何其他异常的完整堆栈跟踪。

用法示例：

django-admin migrate --traceback

指定命令应打印到控制台的通知和调试信息量。

• 0 表示无输出。
• 1 表示正常输出（默认）。
• 2 表示详细输出。
• 3 表示 very 详细输出。

用法示例：

django-admin migrate --verbosity 2

禁用彩色命令输出。 一些命令将其输出格式化为彩色。 例如，错误将以红色打印到控制台，SQL 语句将以语法高亮显示。

用法示例：

django-admin runserver --no-color

如果命令输出被禁用，如 语法着色 中所述，则强制对其进行着色。 例如，您可能希望将彩色输出通过管道传送到另一个命令。

3.0 版中的新功能。

在运行命令之前跳过正在运行的系统检查。 此选项仅在 requires_system_checks 命令属性设置为 True 时可用。

用法示例：

django-admin migrate --skip-checks

额外的细节

语法着色

DJANGO_COLORS

如果您的终端支持 ANSI 彩色输出，django-admin / manage.py 命令将使用漂亮的彩色编码输出。 除非使用 --force-color 选项，否则如果您将命令的输出通过管道传输到另一个程序，它将不会使用颜色代码。

在 Windows 下，本机控制台不支持 ANSI 转义序列，因此默认情况下没有颜色输出。 但是您可以安装 ANSICON 第三方工具，Django 命令将检测它的存在并利用其服务对输出进行着色，就像在基于 Unix 的平台上一样。

可以自定义用于语法突出显示的颜色。 Django 附带三个调色板：

• dark，适用于黑底白字的终端。 这是默认调色板。
• light，适用于白底黑字的终端。
• nocolor，禁用语法高亮。

您可以通过设置 DJANGO_COLORS 环境变量来指定要使用的调色板来选择调色板。 例如，要在 Unix 或 OS/X BASH shell 下指定 light 调色板，您可以在命令提示符下运行以下命令：

export DJANGO_COLORS="light"

您还可以自定义使用的颜色。 Django 指定了许多使用颜色的角色：

• error - 重大错误。
• notice - 一个小错误。
• success - 成功。
• warning - 警告。
• sql_field - SQL 中模型字段的名称。
• sql_coltype - SQL 中模型字段的类型。
• sql_keyword - SQL 关键字。
• sql_table - SQL 中模型的名称。
• http_info - 1XX HTTP 信息服务器响应。
• http_success - 2XX HTTP 成功服务器响应。
• http_not_modified - 304 HTTP 未修改服务器响应。
• http_redirect - 304 以外的 3XX HTTP 重定向服务器响应。
• http_not_found - 404 HTTP Not Found 服务器响应。
• http_bad_request - 404 以外的 4XX HTTP 错误请求服务器响应。
• http_server_error - 5XX HTTP 服务器错误响应。
• migrate_heading - 迁移管理命令中的标题。
• migrate_label - 迁移名称。

可以从以下列表中为这些角色中的每一个分配特定的前景色和背景色：

• black
• red
• green
• yellow
• blue
• magenta
• cyan
• white

然后可以使用以下显示选项修改这些颜色中的每一种：

• bold
• underscore
• blink
• reverse
• conceal

颜色规范遵循以下模式之一：

• role=fg
• role=fg/bg
• role=fg,option,option
• role=fg/bg,option,option

其中 role 是有效颜色角色的名称，fg 是前景色，bg 是背景色，每个 option 是其中一种颜色修改选项。 然后用分号分隔多个颜色规格。 例如：

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

将指定使用蓝色闪烁黄色显示错误，并使用洋红色显示通知。 所有其他颜色角色将保持不变。

还可以通过扩展基本调色板来指定颜色。 如果您将调色板名称放在颜色规范中，则该调色板隐含的所有颜色都将被加载。 所以：

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

将指定使用浅色调色板中的所有颜色， 除外 用于错误和通知的颜色，这些颜色将按指定被覆盖。

Bash 完成

如果您使用 Bash shell，请考虑安装 Django bash 完成脚本，该脚本位于 Django 源代码分发中的 extras/django_bash_completion 中。 它启用 django-admin 和 manage.py 命令的制表符补全，因此您可以，例如……

• 输入 django-admin。
• 按 [TAB] 查看所有可用选项。
• 输入 sql，然后输入 [TAB]，以查看名称以 sql 开头的所有可用选项。

有关如何添加自定义操作，请参阅 编写自定义 django-admin 命令 。

从您的代码运行管理命令

django.core.management.call_command(name, *args, **options)

要从代码中调用管理命令，请使用 call_command。

name

要调用的命令的名称或命令对象。 除非测试需要对象，否则首选传递名称。

*args

命令接受的参数列表。 参数传递给参数解析器，因此您可以使用与在命令行上相同的样式。 例如，call_command('flush', '--verbosity=0')。

**options

命令行上接受的命名选项。 选项被传递给命令而不触发参数解析器，这意味着您需要传递正确的类型。 例如，call_command('flush', verbosity=0)（零必须是整数而不是字符串）。

例子：

from django.core import management
from django.core.management.commands import loaddata

management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)
management.call_command(loaddata.Command(), 'test_data', verbosity=0)

请注意，不带参数的命令选项作为关键字与 True 或 False 一起传递，如您在上面的 interactive 选项中所见。

可以使用以下任一语法传递命名参数：

# Similar to the command line
management.call_command('dumpdata', '--natural-foreign')

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command('dumpdata', use_natural_foreign_keys=True)

使用 call_command() 而不是 django-admin 或 manage.py 时，某些命令选项具有不同的名称。 例如，django-admin createsuperuser --no-input 转换为 call_command('createsuperuser', interactive=False)。 要查找用于 call_command() 的关键字参数名称，请检查传递给 parser.add_argument() 的 dest 参数的命令源代码。

接受多个选项的命令选项会传递一个列表：

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

call_command()函数的返回值与命令的handle()方法的返回值相同。

输出重定向

请注意，您可以重定向标准输出和错误流，因为所有命令都支持 stdout 和 stderr 选项。 例如，你可以写：

with open('/path/to/command_output', 'w') as f:
    management.call_command('dumpdata', stdout=f)