获取运行时帮助¶

django-admin help¶

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

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

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

应用程序名称¶

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

确定版本¶

django-admin version¶

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

输出遵循 PEP 440 中描述的模式。

1.4.dev17026
1.4a1
1.4

显示调试输出¶

使用 --verbosity（在支持的情况下）指定 django-admin 打印到控制台的通知和调试信息量。

check¶

django-admin check [app_label [app_label ...]]¶

使用 系统检查框架 检查整个 Django 项目中是否存在常见问题。

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS¶

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

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

--database DATABASE¶

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

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

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

--list-tags¶

列出所有可用标签。

--deploy¶

激活一些仅在部署环境中才相关的其他检查。

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

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

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

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}¶

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

compilemessages¶

django-admin compilemessages¶

将 makemessages 创建的 .po 文件编译为 .mo 文件，以供内置的 gettext 支持使用。请参阅 国际化和本地化。

--locale LOCALE, -l LOCALE¶

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

--exclude EXCLUDE, -x EXCLUDE¶

指定要从处理中排除的语言环境。如果未提供，则不排除任何语言环境。

--use-fuzzy, -f¶

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

示例用法

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

--ignore PATTERN, -i PATTERN¶

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

示例用法

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

createcachetable¶

django-admin createcachetable¶

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

--database DATABASE¶

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

--dry-run¶

打印将要运行的 SQL 语句，但不实际执行，以便您可以自定义它或使用迁移框架。

dbshell¶

django-admin dbshell¶

运行在您的ENGINE设置中指定的数据库引擎的命令行客户端，并使用您的USER、PASSWORD等设置中指定的连接参数。

• 对于 PostgreSQL，这将运行psql命令行客户端。

• 对于 MySQL，这将运行mysql命令行客户端。

• 对于 SQLite，这将运行sqlite3命令行客户端。

• 对于 Oracle，这将运行sqlplus命令行客户端。

此命令假定程序位于您的PATH中，以便对程序名称（psql、mysql、sqlite3、sqlplus）的调用能够在正确的位置找到程序。无法手动指定程序的位置。

--database DATABASE¶

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

-- ARGUMENTS¶

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

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

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

$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

diffsettings¶

django-admin diffsettings¶

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

在默认设置中未出现的设置后面会跟着"###"。例如，默认设置未定义ROOT_URLCONF，因此ROOT_URLCONF在diffsettings的输出中后面跟着"###"。

--all¶

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

--default MODULE¶

要将当前设置与其进行比较的设置模块。保留为空以与 Django 的默认设置进行比较。

--output {hash,unified}¶

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

dumpdata¶

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]¶

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

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

dumpdata的输出可以用作loaddata的输入。

当dumpdata的结果保存为文件时，它可以用作夹具用于测试或作为初始数据。

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

--all, -a¶

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

--format FORMAT¶

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

--indent INDENT¶

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

--exclude EXCLUDE, -e EXCLUDE¶

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

如果您想排除多个应用程序，请多次传递--exclude。

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

--database DATABASE¶

指定要从中转储数据的数据库。默认为default。

--natural-foreign¶

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

--natural-primary¶

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

--pks PRIMARY_KEYS¶

仅输出由逗号分隔的主键列表指定的对象。此选项仅在转储一个模型时可用。默认情况下，会输出模型的所有记录。

--output OUTPUT, -o OUTPUT¶

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

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

django-admin dumpdata -o mydata.json.gz

flush¶

django-admin flush¶

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

如果您希望从空数据库开始并重新运行所有迁移，则应删除并重新创建数据库，然后运行migrate。

--noinput, --no-input¶

禁止所有用户提示。

--database DATABASE¶

指定要清空的数据库。默认为 default。

inspectdb¶

django-admin inspectdb [table [table ...]]¶

检查 NAME 设置指向的数据库中的数据库表，并将 Django 模型模块（一个 models.py 文件）输出到标准输出。

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

如果您有一个希望使用 Django 的遗留数据库，可以使用此命令。该脚本将检查数据库并为其中的每个表创建一个模型。

正如您可能预期的那样，创建的模型将为表中的每个字段都有一个属性。请注意，inspectdb 在其字段名称输出中有一些特殊情况

• 如果 inspectdb 无法将列的类型映射到模型字段类型，它将使用 TextField 并在生成的模型中字段旁边插入 Python 注释 'This field type is a guess.'。识别的字段可能取决于 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 是其默认值）。

loaddata¶

django-admin loaddata fixture [fixture ...]¶

搜索并加载名为 fixture 的内容到数据库中。

--database DATABASE¶

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

--ignorenonexistent, -i¶

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

--app APP_LABEL¶

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

--format FORMAT¶

指定 序列化格式（例如，json 或 xml）以供 从标准输入读取的 fixture 使用。

--exclude EXCLUDE, -e EXCLUDE¶

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

django-admin loaddata --format=json -

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

makemessages¶

django-admin makemessages¶

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

此命令不需要配置设置。但是，当未配置设置时，该命令无法忽略 MEDIA_ROOT 和 STATIC_ROOT 目录，或包含 LOCALE_PATHS。

--all, -a¶

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

--extension EXTENSIONS, -e EXTENSIONS¶

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

示例用法

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

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

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

--locale LOCALE, -l LOCALE¶

指定要处理的区域设置。

--exclude EXCLUDE, -x EXCLUDE¶

指定要从处理中排除的语言环境。如果未提供，则不排除任何语言环境。

示例用法

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

--domain DOMAIN, -d DOMAIN¶

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

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

• djangojs 用于 *.js 文件

--symlinks, -s¶

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

示例用法

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

--ignore PATTERN, -i PATTERN¶

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

默认情况下使用以下模式：'CVS'、'.*'、'*~'、'*.pyc'。

示例用法

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

--no-default-ignore¶

禁用 --ignore 的默认值。

--no-wrap¶

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

--no-location¶

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

--add-location [{full,file,never}]¶

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

• full（如果未给出则为默认值）：这些行包含文件名和行号。

• file：省略行号。

• never：禁止这些行（与 --no-location 相同）。

需要 gettext 0.19 或更高版本。

--no-obsolete¶

从 .po 文件中删除过时的消息字符串。

--keep-pot¶

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

makemigrations¶

django-admin makemigrations [app_label [app_label ...]]¶

根据检测到的模型更改创建新的迁移。迁移、它们与应用程序的关系以及更多内容在 迁移文档 中进行了深入介绍。

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

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

--noinput, --no-input¶

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

--empty¶

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

--dry-run¶

显示将进行哪些迁移，而无需实际将任何迁移文件写入磁盘。将此选项与 --verbosity 3 一起使用，还将显示将写入的完整迁移文件。

--merge¶

启用修复迁移冲突的功能。

--name NAME, -n NAME¶

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

--no-header¶

生成迁移文件时不包含 Django 版本和时间戳头部信息。

--check¶

当检测到模型更改但没有相应的迁移时，使 makemigrations 退出并返回非零状态码。隐含 --dry-run。

--scriptable¶

将日志输出和用户提示重定向到 stderr，仅将生成迁移文件的路径写入 stdout。

--update¶

将模型更改合并到最新的迁移中，并优化生成的迁移操作。

更新后的迁移将拥有一个自动生成的名称。为了保留之前的名称，可以使用 --name 参数设置名称。

migrate¶

django-admin migrate [app_label] [migration_name]¶

将数据库状态与当前的模型和迁移集同步。迁移、它们与应用的关系等内容在 迁移文档 中有详细介绍。

此命令的行为会根据提供的参数而改变。

• 无参数：所有应用的所有迁移都将被执行。

• <app_label>：指定的应用的迁移将被执行，直到最新的迁移。由于依赖关系，这可能也涉及到执行其他应用的迁移。

• <app_label> <migrationname>：将数据库模式迁移到指定的迁移被应用的状态，但不会应用同一应用中更晚的迁移。如果您之前已经迁移到比指定迁移更晚的版本，这可能涉及到撤销迁移。您可以使用迁移名称的前缀，例如 0001，只要它在给定的应用名称下是唯一的即可。使用名称 zero 可以将所有应用的迁移都撤销，即回滚所有已应用的迁移。

--database DATABASE¶

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

--fake¶

将目标迁移之前的迁移标记为已应用，但不实际运行 SQL 语句来更改数据库模式。

这适用于高级用户，如果他们手动应用更改，可以使用此选项直接操作当前的迁移状态；需要注意的是，使用 --fake 存在使迁移状态表处于需要手动恢复才能使迁移正确运行的状态的风险。

--fake-initial¶

允许 Django 跳过应用的初始迁移，如果所有由该迁移中所有 CreateModel 操作创建的模型的表名已经在数据库中存在。此选项旨在首次针对预先存在于使用迁移之前的数据库运行迁移时使用。但是，此选项不会检查除了表名之外的数据库模式匹配，因此仅当您确信现有模式与初始迁移中记录的模式匹配时才安全使用。

--plan¶

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

--run-syncdb¶

允许为没有迁移的应用创建表。虽然不推荐这样做，但在拥有数百个模型的大型项目中，迁移框架有时速度太慢。

--noinput, --no-input¶

禁止所有用户提示。例如，询问是否删除过时的内容类型。

--check¶

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

--prune¶

从 django_migrations 表中删除不存在的迁移。当被压缩迁移替换的迁移文件已被删除时，这很有用。有关更多详细信息，请参阅 压缩迁移。

optimizemigration¶

django-admin optimizemigration app_label migration_name¶

优化指定迁移的操作，并覆盖现有的迁移文件。如果迁移包含必须手动复制的函数，则该命令会创建一个以 _optimized 为后缀的新迁移文件，该文件旨在替换指定的迁移。

--check¶

当迁移可以被优化时，使 optimizemigration 退出并返回非零状态码。

runserver¶

django-admin runserver [addrport]¶

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

如果您以普通用户权限运行此脚本（推荐），则可能没有权限在低端口号上启动端口。低端口号保留给超级用户（root）。

此服务器使用由 WSGI_APPLICATION 设置指定的 WSGI 应用对象。

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

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

当您启动服务器，以及在服务器运行期间每次更改 Python 代码时，系统检查框架都会检查整个 Django 项目是否存在一些常见错误（请参阅 check 命令）。如果发现任何错误，它们将打印到标准输出。您可以使用 --skip-checks 选项跳过运行系统检查。

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

请注意，默认 IP 地址 127.0.0.1 无法从网络上的其他机器访问。要使开发服务器可供网络上的其他机器查看，请使用其自身的 IP 地址（例如 192.168.2.1）、0（0.0.0.0 的快捷方式）、0.0.0.0 或 ::（启用 IPv6 时）。

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

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

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

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

--noreload¶

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

--nothreading¶

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

--ipv6, -6¶

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

django-admin runserver

django-admin runserver 1.2.3.4:8000

django-admin runserver 7000

django-admin runserver 1.2.3.4:7000

django-admin runserver -6

django-admin runserver -6 7000

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

django-admin runserver localhost:8000

django-admin runserver -6 localhost:8000

sendtestemail¶

django-admin sendtestemail [email [email ...]]¶

将测试电子邮件（确认通过 Django 发送电子邮件是否正常工作）发送到指定的收件人。例如

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

有几个选项，您可以将它们组合在一起使用

--managers¶

使用 mail_managers() 向 MANAGERS 中指定的电子邮件地址发送邮件。

--admins¶

使用 mail_admins() 向 ADMINS 中指定的电子邮件地址发送邮件。

shell¶

django-admin shell¶

启动 Python 交互式解释器。

--interface {ipython,bpython,python}, -i {ipython,bpython,python}¶

指定要使用的 shell。默认情况下，如果安装了 IPython 或 bpython，Django 将使用它们。如果两者都已安装，请指定您想要使用哪个，如下所示

IPython

django-admin shell -i ipython

bpython

django-admin shell -i bpython

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

django-admin shell -i python

--no-startup¶

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

--command COMMAND, -c COMMAND¶

允许您将命令作为字符串传递以将其作为 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-admin showmigrations [app_label [app_label ...]]¶

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

--list, -l¶

列出 Django 知道的全部应用、每个应用可用的迁移，以及每个迁移是否已应用（在迁移名称旁边用 [X] 标记）。对于 --verbosity 为 2 及以上的情况，还会显示应用日期时间。

没有迁移的应用也会列出，但在其下方会打印 (no migrations)。

这是默认的输出格式。

--plan, -p¶

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

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

--database DATABASE¶

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

sqlflush¶

django-admin sqlflush¶

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

--database DATABASE¶

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

sqlmigrate¶

django-admin sqlmigrate app_label migration_name¶

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

请注意，sqlmigrate 不会对其输出进行着色。

--backwards¶

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

--database DATABASE¶

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

sqlsequencereset¶

django-admin sqlsequencereset app_label [app_label ...]¶

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

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

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

--database DATABASE¶

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

squashmigrations¶

django-admin squashmigrations app_label [start_migration_name] migration_name¶

如果可能，将 app_label 的迁移压缩到包括 migration_name 在内的迁移中。生成的压缩迁移可以安全地与未压缩的迁移一起使用。有关更多信息，请阅读 压缩迁移。

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

--no-optimize¶

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

--noinput, --no-input¶

禁止所有用户提示。

--squashed-name SQUASHED_NAME¶

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

--no-header¶

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

startapp¶

django-admin startapp name [directory]¶

为给定的应用名称在当前目录或给定的目标位置创建 Django 应用目录结构。

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

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

例如

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

--template TEMPLATE¶

提供包含自定义应用模板文件的目录的路径，或包含应用模板文件的未压缩归档文件 (.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/main.zip myapp

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

--exclude DIRECTORIES, -x DIRECTORIES¶

指定应用模板中哪些目录应被排除，除了 .git 和 __pycache__。如果未提供此选项，则名称为 __pycache__ 或以 . 开头的目录将被排除。

用于所有匹配文件的 template context 为

• 传递给 startapp 命令的任何选项（在命令支持的选项中）

• app_name – 传递给命令的应用名称

• app_directory – 新创建应用的完整路径

• camel_case_app_name – 驼峰式大小写格式的应用名称

• docs_version – 文档版本：'dev' 或 '1.x'

• django_version – Django 版本，例如 '2.0.3'

startproject¶

django-admin startproject name [directory]¶

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

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

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

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

例如

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

--template TEMPLATE¶

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

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

--exclude DIRECTORIES, -x DIRECTORIES¶

指定项目模板中哪些目录应被排除，除了 .git 和 __pycache__。如果未提供此选项，则名称为 __pycache__ 或以 . 开头的目录将被排除。

使用的 template context 为

• 传递给 startproject 命令的任何选项（在命令支持的选项中）

• project_name – 传递给命令的项目名称

• project_directory – 新创建项目的完整路径

• secret_key – 用于 SECRET_KEY 设置的随机密钥

• docs_version – 文档版本：'dev' 或 '1.x'

• django_version – Django 版本，例如 '2.0.3'

另请参阅 渲染警告 和 受信任代码警告，如 startapp 中所述。

test¶

django-admin test [test_label [test_label ...]]¶

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

--failfast¶

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

--testrunner TESTRUNNER¶

控制用于执行测试的测试运行程序类。此值会覆盖由 TEST_RUNNER 设置提供的值。

--noinput, --no-input¶

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

$ python -m pip install tblib

testserver¶

django-admin testserver [fixture [fixture ...]]¶

使用给定夹具的数据运行 Django 开发服务器（如runserver 中所示）。

例如，此命令

django-admin testserver mydata.json

…将执行以下步骤

1. 创建测试数据库，如测试数据库 中所述。

2. 使用给定夹具中的夹具数据填充测试数据库。（有关夹具的更多信息，请参阅上面loaddata 的文档。）

3. 运行 Django 开发服务器（如runserver 中所示），指向此新创建的测试数据库而不是您的生产数据库。

这在许多方面都很有用

• 当您编写单元测试 以了解您的视图如何在某些夹具数据下运行时，您可以使用 testserver 在 Web 浏览器中手动与视图交互。

• 假设您正在开发 Django 应用程序，并且有一个数据库的“原始”副本，您希望与之交互。您可以将数据库转储到一个夹具（使用dumpdata命令，如上所述），然后使用testserver使用该数据运行您的 Web 应用程序。通过这种安排，您可以灵活地以任何方式弄乱您的数据，因为您知道您所做的任何数据更改都只在测试数据库中进行。

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

--addrport ADDRPORT¶

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

示例

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

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

（以上语句等效。我们同时包含这两个语句是为了说明选项在夹具参数之前还是之后出现都没有关系。）

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

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input¶

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

django.contrib.auth¶

django-admin changepassword ringo

django.contrib.contenttypes¶

django.contrib.gis¶

django.contrib.sessions¶

django.contrib.staticfiles¶

语法着色¶

DJANGO_COLORS¶

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

export DJANGO_COLORS="light"

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 命令。

Black 格式化¶

由 startproject、startapp、optimizemigration、makemigrations 和 squashmigrations 创建的 Python 文件，如果您的 PATH 中存在 black 命令，则将使用该命令进行格式化。

如果您全局安装了 black，但不想将其用于当前项目，则可以显式设置 PATH

PATH=path/to/venv/bin django-admin makemigrations

对于使用 stdout 的命令，如果需要，您可以将输出通过管道传递到 black

django-admin inspectdb | black -