django-admin and manage.py¶django-admin 是Django用于管理任务的命令行实用程序。这份文件概述了它所能做的一切。
此外， manage.py 在每个Django项目中自动创建。它的作用和 django-admin 但也设置了 DJANGO_SETTINGS_MODULE 环境变量，以便它指向项目的 settings.py 文件。
这个 django-admin 如果通过安装Django，脚本应该在系统路径上 pip . 如果它不在您的路径中，请确保您的虚拟环境已激活。
一般来说，在处理一个Django项目时，它更容易使用 manage.py 比 django-admin . 如果需要在多个Django设置文件之间切换，请使用 django-admin 具有 DJANGO_SETTINGS_MODULE 或 --settings 命令行选项。
本文档中的命令行示例使用 django-admin 保持一致，但任何示例都可以使用 manage.py 或 python -m django 同样如此。
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]
command 应该是此文档中列出的命令之一。 options （可选）应为给定命令可用选项的零个或多个。
运行 django-admin help 显示使用信息和每个应用程序提供的命令列表。
运行 django-admin help --commands 显示所有可用命令的列表。
运行 django-admin help <command> 显示给定命令的描述及其可用选项列表。
许多命令采用“应用程序名称”列表。“应用程序名称”是包含模型的包的基名称。例如，如果 INSTALLED_APPS 包含字符串 'mysite.blog' ，应用程序名称为 blog .
运行 django-admin version 显示当前的Django版本。
输出遵循中所述的架构 PEP 440 ：
1.4.dev17026
1.4a1
1.4
使用 --verbosity ，以指定通知和调试信息量， django-admin 打印到控制台。
check¶使用 system check framework 检查整个Django项目的常见问题。
默认情况下，将选中所有应用程序。您可以通过提供应用程序标签列表作为参数来检查应用程序子集：
django-admin check auth admin myapp
系统检查框架执行许多不同类型的检查，这些检查 categorized with tags 。您可以使用这些标记将执行的检查限制为特定类别中的检查。例如，要仅执行型号和兼容性检查，请运行：
django-admin check --tag models --tag compatibility
指定要运行需要数据库访问权限的检查的数据库：
django-admin check --database default --database other
默认情况下，不会运行这些检查。
列出所有可用的标记。
激活一些仅与部署设置相关的附加检查。
您可以在本地开发环境中使用此选项，但由于您的本地开发设置模块可能没有许多生产设置，因此您可能希望将 check 命令放置在不同的设置模块中，方法是将 DJANGO_SETTINGS_MODULE 环境变量，或通过将 --settings 选项：
django-admin check --deploy --settings=production_settings
或者您可以直接在生产部署或临时部署上运行它，以验证是否正在使用正确的设置（省略 --settings ）甚至可以将其作为集成测试套件的一部分。
指定将导致命令以非零状态退出的消息级别。默认是 ERROR .
compilemessages¶编译 .po 文件创建者 makemessages 到 .mo 用于内置GetText支持的文件。见 国际化与本土化 .
指定要处理的区域设置。如果未提供，则处理所有区域设置。
指定要从处理中排除的区域设置。如果未提供，则不排除任何区域设置。
包括 fuzzy translations 到编译文件中。
用法示例：
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
忽略与给定目录匹配的目录 glob -款式图案。多次使用可忽略更多。
用法示例：
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
createcachetable¶使用设置文件中的信息创建用于数据库缓存后端的缓存表。见 Django的缓存框架 更多信息。
指定将在其中创建缓存表的数据库。默认为 default .
打印将在不实际运行的情况下运行的SQL，因此您可以自定义它或使用迁移框架。
dbshell¶为中指定的数据库引擎运行命令行客户端 ENGINE 设置，使用您的 USER ， PASSWORD 等等，设置。
对于PostgreSQL，这运行 psql 命令行客户端。
对于MySQL，这运行 mysql 命令行客户端。
对于sqlite，这将运行 sqlite3 命令行客户端。
对于Oracle，这运行 sqlplus 命令行客户端。
此命令假定程序位于 PATH 所以对程序名的调用 (psql ， mysql ， sqlite3 ， sqlplus ）将在正确的位置找到程序。无法手动指定程序的位置。
指定要打开Shell程序的数据库。默认为 default .
后面的任何参数 -- 分隔符将被传递到底层命令行客户端。例如，对于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的默认设置（或由指定的其他设置文件）之间的差异 --default ）
不在默认值中显示的设置后跟 "###" . 例如，默认设置没有定义 ROOT_URLCONF 如此 ROOT_URLCONF 其次是 "###" 在输出中 diffsettings .
显示所有设置，即使它们具有Django的默认值。这些设置的前缀是 "###" .
用于比较当前设置的设置模块。保留为空以与Django的默认设置进行比较。
指定输出格式。可用值为 hash 和 unified . hash 是显示上述输出的默认模式。 unified 显示的输出类似于 diff -u . 默认设置的前缀是减号，然后是以加号作为前缀的更改设置。
dumpdata¶输出到标准输出数据库中与指定应用程序关联的所有数据。
如果没有提供应用程序名称，则将转储所有已安装的应用程序。
产量 dumpdata 可作为输入 loaddata .
当结果为 dumpdata 另存为文件，则它可以作为 fixture 为 tests 或作为一种 initial data 。
注意 dumpdata 使用模型上的默认管理器选择要转储的记录。如果你用的是 custom manager 作为默认的管理器，它过滤一些可用的记录，并不是所有的对象都将被转储。
使用Django的基本管理器，转储可能被自定义管理器过滤或修改的记录。
指定输出的序列化格式。默认为JSON。支持的格式列在 序列化格式 .
指定要在输出中使用的缩进空格数。默认为 None 它在单行上显示所有数据。
阻止特定的应用程序或模型(以 app_label.ModelName )不会被抛弃。如果指定模型名称，则只排除该模型，而不是整个应用程序。您还可以混合使用应用程序名称和模型名称。
如果要排除多个应用程序，请传递 --exclude 不止一次：
django-admin dumpdata --exclude=auth --exclude=contenttypes
指定将从中转储数据的数据库。默认为 default .
使用 natural_key() 模型方法，用于序列化任何外键以及与定义该方法的类型的对象的多对多关系。如果你在倾倒 contrib.auth Permission 对象或 contrib.contenttypes ContentType 对象，您可能应该使用此标志。见 natural keys 有关此选项和下一个选项的详细信息，请参阅文档。
省略此对象的序列化数据中的主键，因为可以在反序列化期间计算它。
只输出由逗号分隔的主键列表指定的对象。这仅在转储一个模型时可用。默认情况下，将输出模型的所有记录。
指定要将序列化数据写入的文件。默认情况下，数据转到标准输出。
当设置此选项时，并且 --verbosity 大于0（默认值），终端中显示进度条。
输出文件可以使用以下选项之一进行压缩 bz2 ， gz ， lzma ，或 xz 通过以相应的扩展名结束文件名来格式化。例如，要将数据输出为压缩的JSON文件：
django-admin dumpdata -o mydata.json.gz
flush¶从数据库中删除所有数据并重新执行任何后同步处理程序。尚未清除已应用迁移的表。
如果您希望从空数据库开始并重新运行所有迁移，则应删除并重新创建数据库，然后运行 migrate 取而代之的是。
禁止所有用户提示。
指定要刷新的数据库。默认为 default .
inspectdb¶自省数据库中由 NAME 设置并输出Django模型模块（A models.py 文件）到标准输出。
您可以通过将表或视图的名称作为参数传递来选择要检查的表或视图。如果没有提供参数，则仅当 --include-views 使用选项。如果 --include-partitions 使用选项。
如果您有一个要使用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.' 在场地旁边。
这个特性意味着作为一个快捷方式，而不是确定的模型生成。运行它之后，您将希望自己检查生成的模型以进行自定义。特别是，您需要重新排列模型的顺序，以便正确地订购引用其他模型的模型。
Django不会在 default 在模型字段上指定。同样，数据库默认值不会被转换为模型字段默认值，也不会被检测到。 inspectdb .
默认情况下， inspectdb 创建非托管模型。也就是说， managed = False 在模型中 Meta 类告诉Django不要管理每个表的创建、修改和删除。如果您希望允许Django管理表的生命周期，则需要更改 managed 选择权 True （或者移除它是因为 True 是其默认值）。
为物化视图创建模型，如果 --include-views 使用。
为外部表创建模型。
为物化视图创建模型，如果 --include-views 使用。
如果 --include-partitions 使用。
指定要自省的数据库。默认为 default .
如果提供此选项，则还为分区创建模型。
只实现了对PostgreSQL的支持。
如果提供此选项，还将为数据库视图创建模型。
loaddata¶搜索并加载命名的 fixture 输入到数据库中。
指定将数据加载到其中的数据库。默认为 default .
忽略自最初生成设备以来可能已移除的字段和模型。
指定要在其中查找设备的单个应用程序，而不是在所有应用程序中查找设备。
指定 serialization format （例如， json 或 xml 固定装置 read from stdin .
不包括从给定的应用程序和/或模型（形式为 app_label 或 app_label.ModelName ）多次使用该选项排除多个应用程序或模型。
stdin¶您可以使用破折号作为装入输入的装置名称 sys.stdin 。例如：
django-admin loaddata --format=json -
当从 stdin , the --format 需要选项来指定 serialization format 输入（例如， json 或 xml ）
加载自 stdin 对于标准输入和输出重定向非常有用。例如：
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
这个 dumpdata 命令可用于生成 loaddata .
参见
有关灯具的更多详细信息，请参阅 固定装置 主题。
makemessages¶在当前目录的整个源代码树上运行，并拉出所有标记为要转换的字符串。它在conf/locale（在django树中）或locale（用于项目和应用程序）目录中创建（或更新）消息文件。对消息文件进行更改后，需要使用 compilemessages 用于内置GetText支持。见 i18n documentation 有关详细信息。
此命令不需要配置的设置。但是，如果未配置设置，则命令不能忽略 MEDIA_ROOT 和 STATIC_ROOT 目录或包含 LOCALE_PATHS .
更新所有可用语言的邮件文件。
指定要检查的文件扩展名列表（默认： html ， txt ， py 或 js 如果 --domain 是 js ）
用法示例：
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 创建之前生成的文件 .po 文件。这对于调试可能阻止创建最终语言文件的错误很有用。
参见
见 定制 makemessages 命令 有关如何自定义 makemessages 传到 xgettext .
makemigrations¶根据检测到的模型更改创建新的迁移。迁移、它们与应用程序的关系以及更多内容在 the migrations documentation .
提供一个或多个应用程序名称作为参数将限制创建到指定应用程序的迁移以及所需的任何依赖项（位于 ForeignKey 例如。
将迁移添加到没有 migrations 目录，运行 makemigrations 应用程序的 app_label .
禁止所有用户提示。如果无法自动解决抑制的提示，则命令将退出，并返回错误代码3。
为指定的应用程序输出空迁移，以进行手动编辑。这适用于高级用户，除非您熟悉迁移格式、迁移操作和迁移之间的依赖关系，否则不应使用。
显示在不将任何迁移文件写入磁盘的情况下进行的迁移。将此选项与 --verbosity 3 还将显示将要写入的完整迁移文件。
允许修复迁移冲突。
允许命名生成的迁移，而不是使用生成的名称。名称必须是有效的python identifier .
生成没有django版本和时间戳头的迁移文件。
vbl.使 makemigrations 当检测到模型更改而没有移植时，以非零状态退出。暗示 --dry-run 。
将日志输出和输入提示转移到 stderr ，仅将生成的迁移文件的路径写入 stdout 。
将模型更改合并到最新的迁移中，并优化结果操作。
更新后的迁移将具有生成的名称。为了保留以前的名称，请使用 --name 。
migrate¶将数据库状态与当前的一组模型和迁移进行同步。迁移、它们与应用程序的关系以及更多内容在 the migrations documentation .
此命令的行为将根据提供的参数而更改：
没有参数：所有应用程序都运行了所有迁移。
<app_label> ：指定的应用程序已运行迁移，直至最近的迁移。这可能也涉及到运行其他应用程序的迁移，这是由于依赖关系。
<app_label> <migrationname> ：使数据库架构处于应用命名迁移的状态，但不会应用同一应用程序中的以后迁移。如果您以前迁移过指定的迁移，则这可能涉及未应用的迁移。您可以使用迁移名称的前缀，例如。 0001 ，只要它对于给定的应用程序名称是唯一的。用这个名字 zero 一路向后迁移，即恢复应用程序的所有迁移。
警告
取消应用迁移时，所有依赖迁移也将被取消应用，无论 <app_label> . 你可以使用 --plan 以检查哪些迁移将被取消应用。
指定要迁移的数据库。默认为 default .
将迁移到目标迁移（遵循上面的规则）标记为已应用，但实际上不运行SQL来更改数据库架构。
这是为了让高级用户在手动应用更改时直接操作当前迁移状态；请注意，使用 --fake 存在将迁移状态表置于需要手动恢复才能使迁移正确运行的状态的风险。
允许Django跳过应用程序的初始迁移，前提是所有数据库表的名称都是由all创建的所有模型的名称 CreateModel 该迁移中的操作已存在。此选项用于首次针对先前使用迁移的数据库运行迁移时。但是，此选项不检查匹配表名之外的匹配数据库架构，因此只有在确信现有架构与初始迁移中记录的内容匹配时才可以安全使用。
显示将为给定的 migrate 命令。
允许在不迁移的情况下为应用程序创建表。虽然不建议这样做，但在拥有数百个模型的大型项目上，迁移框架有时速度太慢。
取消所有用户提示。示例提示询问如何删除过时的内容类型。
使 migrate 当检测到未应用的迁移时，以非零状态退出。
将不存在的迁移从 django_migrations 桌子。当被压缩的迁移替换的迁移文件已被删除时，这很有用。看见 挤压迁移 了解更多详细信息。
optimizemigration¶优化命名迁移的操作并覆盖现有文件。如果迁移包含必须手动复制的函数，该命令将创建一个新的迁移文件，其后缀为 _optimized 这意味着要替换命名迁移。
vbl.使 optimizemigration 在可以优化迁移时以非零状态退出。
runserver¶在本地计算机上启动轻量级开发Web服务器。默认情况下，服务器在IP地址的端口8000上运行 127.0.0.1 。您可以显式传入IP地址和端口号。
如果以具有正常权限（推荐）的用户身份运行此脚本，则可能无法在低端口号上启动端口。低端口号是为超级用户（根）保留的。
此服务器使用由 WSGI_APPLICATION 设置。
请勿在生产设置中使用此服务器。它没有通过安全审计或性能测试。(这就是它将如何保持下去。我们从事的业务是制作Web框架，而不是Web服务器，因此改进该服务器以处理生产环境超出了Django的范围。)
开发服务器根据需要自动为每个请求重新加载python代码。您不需要重新启动服务器，代码更改就可以生效。但是，一些操作（如添加文件）不会触发重新启动，因此在这些情况下，您必须重新启动服务器。
如果您使用的是Linux或MacOS并同时安装了这两种操作系统 pywatchman 以及 Watchman 服务，内核信号将用于自动重新加载服务器(而不是每秒轮询文件修改时间戳)。这在大型项目上提供了更好的性能、缩短了代码更改后的响应时间、更强大的更改检测，并减少了功耗。Django支持 pywatchman 1.2.0及更高版本。
包含许多文件的大型目录可能会导致性能问题
当在包含大型非python目录的项目中使用watchman时， node_modules ，建议忽略此目录以获得最佳性能。见 watchman documentation 有关如何执行此操作的信息。
启动服务器时，每次在服务器运行期间更改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 已启用contrib app（新项目中的默认值） runserver 命令将被自己的命令覆盖 runserver 命令。
将服务器的每个请求和响应的日志发送到 django.server 记录器。
禁用自动重新加载。这意味着在服务器运行时对python代码所做的任何更改都将 not 如果特定的python模块已经加载到内存中，则生效。
禁止在开发服务器中使用线程。默认情况下，服务器是多线程的。
将IPv6用于开发服务器。这将更改默认IP地址 127.0.0.1 到 ::1 .
IP地址上的端口8000 127.0.0.1 ：
django-admin runserver
IP地址上的端口8000 1.2.3.4 ：
django-admin runserver 1.2.3.4:8000
IP地址上的端口7000 127.0.0.1 ：
django-admin runserver 7000
IP地址上的端口7000 1.2.3.4 ：
django-admin runserver 1.2.3.4:7000
IPv6地址上的端口8000 ::1 ：
django-admin runserver -6
IPv6地址上的端口7000 ::1 ：
django-admin runserver -6 7000
IPv6地址上的端口7000 2001:0db8:1234:5678::9 ：
django-admin runserver [2001:0db8:1234:5678::9]:7000
主机的IPv4地址上的端口8000 localhost ：
django-admin runserver localhost:8000
主机的IPv6地址上的端口8000 localhost ：
django-admin runserver -6 localhost:8000
默认情况下，开发服务器不为您的站点提供任何静态文件（如CSS文件、图像、下面的内容） MEDIA_URL 等等。如果要配置django为静态媒体提供服务，请阅读 如何管理静态文件(如图像、JavaScript、css) .
姜戈的 runserver 命令提供了一个WSGI服务器。为了在ASGI下运行，您需要使用 ASGI server 。Django Daphne项目提供 与 runserver 你可以用它。
sendtestemail¶向指定的收件人(S)发送测试电子邮件(以确认通过Django发送的电子邮件正常工作)。例如：
django-admin sendtestemail foo@example.com bar@example.com
有几个选项，您可以将它们组合在一起使用：
邮件中指定的电子邮件地址 MANAGERS 使用 mail_managers() .
邮件中指定的电子邮件地址 ADMINS 使用 mail_admins() .
shell¶启动python交互式解释器。
指定要使用的Shell。默认情况下，Django将使用 IPython 或 bpython 如果安装了任何一个。如果两个都安装了，请指定您要的类型：
IPython：
django-admin shell -i ipython
Bpython：
django-admin shell -i bpython
如果您已经安装了一个“富”的Shell，但是想要强制使用“普通的”Python解释器，那么可以使用 python 作为接口名称，如下所示：
django-admin shell -i python
禁止读取“plain”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() 在那个平台上。
showmigrations¶显示项目中的所有迁移。您可以从两种格式中选择一种：
列出Django知道的所有应用程序、每个应用程序可用的迁移，以及是否应用每个迁移（用 [X] 在迁移名称旁边）。对于一个 --verbosity 其中2个及以上，应用的日期时间也显示。
也列出了没有迁移的应用程序，但 (no migrations) 印在下面。
这是默认的输出格式。
显示Django将遵循的迁移计划以应用迁移。喜欢 --list ，应用的迁移用 [X] . 对于一个 --verbosity 在2和更高版本中，还将显示迁移的所有依赖项。
app_label S参数限制了输出，但是也可能包括所提供应用程序的依赖项。
指定要检查的数据库。默认为 default .
sqlflush¶打印将为执行的SQL语句 flush 命令。
指定要为其打印SQL的数据库。默认为 default .
sqlmigrate¶打印用于命名迁移的SQL。这需要一个活动的数据库连接，该连接将用于解析约束名；这意味着您必须根据以后要应用它的数据库的副本生成SQL。
注意 sqlmigrate 不着色其输出。
生成用于取消应用迁移的SQL。默认情况下，创建的SQL用于向前运行迁移。
指定要为其生成SQL的数据库。默认为 default .
sqlsequencereset¶打印用于重置给定应用程序名称序列的SQL语句。
序列是一些数据库引擎用来跟踪自动递增字段下一个可用数字的索引。
使用此命令生成SQL，它将修复序列与其自动递增的字段数据不同步的情况。
指定要为其打印SQL的数据库。默认为 default .
squashmigrations¶挤压迁移 app_label 直至并包括 migration_name 尽可能减少迁移。由此产生的压扁迁移可以与未压扁的迁移一起安全地生活。有关更多信息，请阅读 挤压迁移 .
什么时候？ start_migration_name 如果给定，django将只包括从该迁移开始并包括该迁移的迁移。这有助于减轻 RunPython 和 django.db.migrations.operations.RunSQL 迁移操作。
生成压缩迁移时禁用优化器。默认情况下，Django将尝试优化迁移中的操作，以减小结果文件的大小。如果此过程失败或创建的迁移不正确，请使用此选项，但请同时提交有关该行为的Django Bug报告，因为优化是安全的。
禁止所有用户提示。
设置压缩迁移的名称。省略时，名称基于第一次和最后一次迁移，使用 _squashed_ 介于两者之间。
生成不带django版本和时间戳头的压缩迁移文件。
startapp¶为当前目录或给定目标中的给定应用程序名称创建Django应用程序目录结构。
默认情况下， the new directory 包含一个 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的功能将存储库公开为压缩文件，您可以使用如下URL：
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
指定应用程序模板中应使用模板引擎呈现的文件扩展名。默认为 py .
指定应用程序模板中的哪些文件（除了那些匹配的文件 --extension ）应使用模板引擎呈现。默认为空列表。
指定应排除应用程序模板中的哪些目录 .git and __pycache__. If this option is not provided, directories named __pycache__ or starting with . 将被排除在外。
这个 template context 用于所有匹配文件的是：
任何传递给 startapp 命令（在命令支持的选项中）
app_name --传递给命令的应用程序名称
app_directory --新创建的应用程序的完整路径
camel_case_app_name --应用程序名称采用驼色大小写格式
docs_version -- the version of the documentation: 'dev' or '1.x'
django_version -- the version of Django, e.g. '2.0.3'
警告
当使用django模板引擎呈现应用程序模板文件时（默认情况下，所有 *.py 文件），django也将替换包含的所有杂散模板变量。例如，如果其中一个python文件包含解释与模板呈现相关的特定功能的docstring，则可能导致不正确的示例。
要解决此问题，可以使用 templatetag 模板标记“转义”模板语法的各个部分。
此外，允许包含django模板语言语法的python模板文件，同时防止打包系统尝试字节编译无效 *.py 文件，以结尾的模板文件 .py-tpl 将重命名为 .py .
警告
自定义应用程序(或项目)模板的内容应始终在使用前进行审核：此类模板定义了将成为项目一部分的代码，这意味着此类代码将与您安装的任何应用程序或您自己编写的代码一样受信任。此外，即使呈现模板也是有效地执行作为管理命令的输入提供的代码。Django模板语言可以提供对系统的广泛访问，因此请确保您使用的任何定制模板都值得您信任。
startproject¶为当前目录或给定目标中的给定项目名称创建Django项目目录结构。
默认情况下， the new directory 包含 manage.py 和项目包（包含 settings.py 以及其他文件）。
如果只给定项目名称，则将同时命名项目目录和项目包。 <projectname> 项目目录将在当前工作目录中创建。
如果提供了可选的目标，Django将使用该现有目录作为项目目录，并创建 manage.py 以及其中的项目包。使用“.”表示当前工作目录。
例如：
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
指定自定义项目模板的目录、文件路径或URL。见 startapp --template 示例和用法文档。
指定应使用模板引擎呈现项目模板中的哪些文件扩展名。默认为 py .
指定项目模板中的哪些文件（除了那些匹配的文件之外 --extension ）应使用模板引擎呈现。默认为空列表。
指定应排除项目模板中的哪些目录 .git and __pycache__. If this option is not provided, directories named __pycache__ or starting with . 将被排除在外。
这个 template context 用途是：
任何传递给 startproject 命令（在命令支持的选项中）
project_name --传递给命令的项目名称
project_directory --新创建项目的完整路径
secret_key --一个随机键 SECRET_KEY 设置
docs_version -- the version of the documentation: 'dev' or '1.x'
django_version -- the version of Django, e.g. '2.0.3'
另请参阅 rendering warning 和 trusted code warning 如上所述 startapp 。
test¶对所有已安装的应用程序运行测试。见 Django测试 更多信息。
停止运行测试，并在测试失败后立即报告失败。
控制用于执行测试的测试运行程序类。此值覆盖 TEST_RUNNER 设置。
禁止所有用户提示。典型的提示是关于删除现有测试数据库的警告。
这个 test 命令代表指定的接收选项 --testrunner . 以下是默认测试运行程序的选项： DiscoverRunner .
在测试运行之间保留测试数据库。这样做的好处是可以跳过create和destroy操作，这可以大大减少运行测试的时间，尤其是大型测试套件中的测试。如果测试数据库不存在，它将在第一次运行时创建，然后为以后的每次运行保留。除非 MIGRATE 测试设置为 False ，在运行测试套件之前，任何未应用的迁移也将应用于测试数据库。
在运行测试之前对测试顺序进行随机化。这有助于检测未正确隔离的测试。此选项生成的测试顺序是给定整数种子的确定性函数。当没有传递种子时，随机选择一个种子并打印到控制台。要重复特定的测试顺序，请传递种子。此选项生成的测试订单保留Django的 guarantees on test order 。它们还按测试用例类别对测试进行分组。
混洗后的排序还具有一种特殊的一致性属性，在缩小隔离问题的范围时很有用。也就是说，对于给定的种子，当运行测试的子集时，新的顺序将是限于较小集的原始改组。类似地，当在保持种子不变的情况下添加测试时，原始测试的顺序将在新的顺序中相同。
以相反的执行顺序对测试用例进行排序。这可能有助于调试未正确隔离的测试的副作用。 Grouping by test class 使用此选项时将保留。这可以与一起使用 --shuffle 颠倒特定种子的顺序。
设置 DEBUG 设置为 True 在运行测试之前。这可能有助于排除测试故障。
使能够 SQL logging 测试失败。如果 --verbosity 是 2 ，然后输出通过测试中的查询。
在单独的并行进程中运行测试。由于现代处理器有多个内核，这使得运行测试的速度大大加快。
vbl.使用 --parallel 没有值，或具有值 auto ，对每个内核运行一个测试进程，根据 multiprocessing.cpu_count() 。您可以通过传递所需数量的进程来覆盖它，例如 --parallel 4 ，或通过设置 DJANGO_TEST_PROCESSES 环境变量。
Django分发测试用例- unittest.TestCase 子类-到子进程。如果测试用例类少于配置的进程，Django将相应地减少进程的数量。
每个进程都有自己的数据库。您必须确保不同的测试用例类不会访问相同的资源。例如，接触文件系统的测试用例类应该创建一个临时目录供自己使用。
备注
如果您有无法并行运行的测试类，则可以使用 SerializeMixin 按顺序运行它们。看到了吗 Enforce running test classes sequentially .
此选项需要第三方 tblib 要正确显示回溯的包：
$ python -m pip install tblib
此功能在Windows上不可用。它也不适用于Oracle数据库后端。
如果你想用 pdb 调试测试时，必须禁用并行执行 (--parallel=1 ）你会看到 bdb.BdbQuit 如果你不这样做。
警告
当启用测试并行化且测试失败时，Django可能无法显示异常跟踪。这会使调试变得困难。如果遇到此问题，请运行受影响的测试而不进行并行化，以查看故障的回溯。
这是一个已知的限制。它产生于需要序列化对象以便在进程之间交换它们。见 What can be pickled and unpickled? 有关详细信息。
只运行测试 marked with the specified tags . 可多次指定并与 test --exclude-tag .
加载失败的测试始终被视为匹配。
排除测试 marked with the specified tags . 可多次指定并与 test --tag .
运行与测试名称模式匹配的测试方法和类，方法与 unittest's -k option . 可以多次指定。
生成 pdb 每次测试错误或失败时的调试器。如果你安装了它， ipdb 而是使用。
丢弃输出 (stdout 和 stderr )为了通过测试，与 unittest's --buffer option .
Django自动呼叫 faulthandler.enable() 当启动测试时，它允许在解释器崩溃时打印回溯。通过 --no-faulthandler 禁用此行为。
输出计时，包括数据库设置和总运行时间。
显示了N个最慢的测试用例(N=0)。
Python3.12及更高版本
此功能仅在Python3.12及更高版本中可用。
testserver¶运行Django开发服务器（如 runserver ）使用给定夹具的数据。
例如，此命令：
django-admin testserver mydata.json
…将执行以下步骤：
创建测试数据库，如中所述 测试数据库 .
用给定夹具的夹具数据填充测试数据库。（有关固定装置的更多信息，请参见 loaddata 以上）
运行Django开发服务器（如 runserver ，指向这个新创建的测试数据库，而不是您的生产数据库。
这在很多方面都很有用：
当你在写作的时候 unit tests 关于您的视图如何处理某些装置数据，您可以使用 testserver 要在Web浏览器中与视图交互，请手动。
假设您正在开发Django应用程序，并且有一个您想要与之交互的数据库的“原始”副本。您可以将数据库转储到 fixture (使用 dumpdata 命令)，然后使用 testserver 使用该数据运行您的Web应用程序。通过这种安排，您可以灵活地以任何方式扰乱您的数据，因为您知道所做的任何数据更改都只是对测试数据库进行的。
请注意，此服务器 not 自动检测对python源代码的更改（如 runserver 做）。但是，它会检测到对模板的更改。
指定与默认值不同的端口或IP地址和端口 127.0.0.1:8000 . 该值的格式与 runserver 命令。
实例：
使用以下命令在端口7000上运行测试服务器 fixture1 和 fixture2 ：
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
（上述陈述是等效的。我们将这两个选项都包括在内，以证明选项是在fixture参数之前还是之后出现并不重要。）
在1.2.3.4：7000上运行 test 固定装置：
django-admin testserver --addrport 1.2.3.4:7000 test
禁止所有用户提示。典型的提示是关于删除现有测试数据库的警告。
只有当 django.contrib 应用程序 implements 他们已经 enabled . 本节将按应用程序对它们进行分组。
django.contrib.auth¶changepassword¶此命令仅在Django的 authentication system (django.contrib.auth ）已安装。
允许更改用户密码。它会提示您为给定用户输入两次新密码。如果条目相同，这将立即成为新密码。如果不提供用户，该命令将尝试更改其用户名与当前用户匹配的密码。
指定要为用户查询的数据库。默认为 default .
用法示例：
django-admin changepassword ringo
createsuperuser¶此命令仅在Django的 authentication system (django.contrib.auth ）已安装。
创建超级用户帐户（拥有所有权限的用户）。如果需要创建初始超级用户帐户，或者需要以编程方式为站点生成超级用户帐户，则此选项非常有用。
当以交互方式运行时，此命令将提示输入新超级用户帐户的密码。以非交互方式运行时，可以通过设置 DJANGO_SUPERUSER_PASSWORD 环境变量。否则，将不设置密码，并且超级用户帐户将无法登录，直到手动为其设置密码。
在非交互式模式下 USERNAME_FIELD 和必填字段（列在 REQUIRED_FIELDS )回到 DJANGO_SUPERUSER_<uppercase_field_name> 环境变量，除非它们被命令行参数重写。例如，提供 email field，你可以用 DJANGO_SUPERUSER_EMAIL 环境变量。
取消所有用户提示。如果不能用“退出”代码来解决，则“退出”命令不能自动解决。
新帐户的用户名和电子邮件地址可以通过使用 --username 和 --email 命令行上的参数。如果其中一个没有提供， createsuperuser 以交互方式运行时将提示输入。
指定将超级用户对象保存到其中的数据库。
您可以将管理命令子类化并重写 get_input_data() 如果要自定义数据输入和验证。有关现有实现和方法参数的详细信息，请参考源代码。例如，如果您有一个 ForeignKey 在里面 REQUIRED_FIELDS 并希望允许创建实例而不是输入现有实例的主键。
django.contrib.contenttypes¶remove_stale_contenttypes¶此命令仅在Django的 contenttypes app (django.contrib.contenttypes ）已安装。
删除数据库中过时的内容类型（从已删除的模型中）。依赖于已删除内容类型的任何对象也将被删除。在确认可以继续删除之前，将显示已删除对象的列表。
指定要使用的数据库。默认为 default .
删除过时的内容类型，包括从以前安装的应用程序中删除的内容类型 INSTALLED_APPS .默认为 False .
django.contrib.gis¶ogrinspect¶此命令仅在以下情况下可用： GeoDjango (django.contrib.gis ）已安装。
请参考其 description 在geodjango文档中。
django.contrib.sessions¶clearsessions¶可以作为cron作业运行，也可以直接清除过期的会话。
django.contrib.staticfiles¶collectstatic¶只有当 static files application (django.contrib.staticfiles ）已安装。
请参考其 description 在 staticfiles 文档。
findstatic¶只有当 static files application (django.contrib.staticfiles ）已安装。
请参考其 description 在 staticfiles 文档。
尽管某些命令可能允许使用其自己的自定义选项，但默认情况下，每个命令都允许使用以下选项：
将给定的文件系统路径添加到python import search path . 如果没有提供， 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 发生并对任何其他异常执行完整的堆栈跟踪。
此选项将被忽略 runserver 。
用法示例：
django-admin migrate --traceback
指定命令应打印到控制台的通知和调试信息量。
0 表示没有输出。
1 表示正常输出（默认）。
2 表示详细输出。
3 方法 very 冗长的输出。
此选项将被忽略 runserver 。
用法示例：
django-admin migrate --verbosity 2
禁用彩色命令输出。有些命令将输出格式化为彩色。例如，错误将以红色打印到控制台，SQL语句将突出显示语法。
用法示例：
django-admin runserver --no-color
如中所述，如果命令输出否则将被禁用，则强制对其着色。 语法颜色标记 . 例如，您可能希望将彩色输出通过管道传输到另一个命令。
在运行命令之前跳过运行系统检查。此选项仅在 requires_system_checks 命令属性不是空列表或元组。
用法示例：
django-admin migrate --skip-checks
这个 django-admin / manage.py 如果终端支持ANSI彩色输出，命令将使用漂亮的彩色编码输出。如果将命令的输出通过管道传输到其他程序，则不会使用颜色代码，除非 --force-color 使用选项。
在Windows 10上， Windows Terminal 申请， VS Code 和PowerShell(其中启用了虚拟终端处理)允许彩色输出，并且在默认情况下受支持。
在Windows下，旧版 cmd.exe 本机控制台不支持ANSI转义序列，因此默认情况下没有颜色输出。在这种情况下，需要两个第三方库中的任何一个：
安装 colorama ，这是一个将ANSI颜色代码转换为Windows API调用的Python包。Django命令将检测到它的存在，并将利用其服务进行色彩输出，就像在基于Unix的平台上一样。 colorama 可通过PIP安装：
...\> py -m pip install "colorama >= 0.4.6"
安装 ANSICON ，这是一个第三方工具，它允许 cmd.exe 处理ANSI色码。Django命令将检测到它的存在，并将利用其服务进行颜色输出，就像在基于Unix的平台上一样。
Windows上的其他现代终端环境(支持终端颜色，但Django不会自动检测到这些环境)可能会“伪造”安装 ANSICON 通过设置适当的环境变量， ANSICON="on" 。
可自定义用于语法突出显示的颜色。Django提供三种颜色调色板：
dark 适用于在黑色背景上显示白色文本的终端。这是默认调色板。
light 适用于在白色背景上显示黑色文本的终端。
nocolor ，这将禁用语法突出显示。
您可以通过设置 DJANGO_COLORS 环境变量来指定要使用的调色板。例如，要指定 light 调色板在Unix或OS/X BashShell下，您可以在命令提示符下运行以下命令：
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 -3xx HTTP重定向服务器响应，而不是304。
http_not_found -404 HTTP未找到服务器响应。
http_bad_request -4xx HTTP错误请求服务器响应而不是404。
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"
将指定使用浅色调色板中的所有颜色， 除了 用于错误和通知的颜色，这些颜色将按指定内容覆盖。
如果您使用BashShell，请考虑安装Django bash完成脚本，该脚本位于 extras/django_bash_completion 在Django源代码分发中。它支持按Tab键完成 django-admin 和 manage.py 命令，这样你就可以，例如..。
类型 django-admin .
出版社 [TAB] 查看所有可用选项。
类型 sql 然后 [TAB] ，以查看名称以开头的所有可用选项 sql .
见 如何创建自定义 django-admin 命令 如何添加自定义操作。
由创建的Python文件 startproject ， startapp ， optimizemigration ， makemigrations ，以及 squashmigrations 格式设置为使用 black 命令(如果该命令存在于 PATH 。
如果你有 black 全局安装，但不希望将其用于当前项目，则可以设置 PATH 明确地说：
PATH=path/to/venv/bin django-admin makemigrations
对于命令，请使用 stdout 您可以通过管道将输出发送到 black 如果需要，请执行以下操作：
django-admin inspectdb | black -
要从代码调用管理命令，请使用 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() ，检查命令的源代码 dest 参数传递给 parser.add_argument() .
采用多个选项的命令选项将传递一个列表：
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)
12月 18, 2023