1.4.dev17026
1.4a1
激活一些仅在部署环境中相关的附加检查。
你可以在本地开发环境中使用这个选项，但由于你的本地开发设置模块可能不包含许多生产设置，所以你可能希望将 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
指定要处理的 locale。如果没有提供，则会处理所有的 locale。
--exclude EXCLUDE, -x EXCLUDE
指定要从处理中排除的 locale。如果没有提供，则不排除任何 locale。
--use-fuzzy, -f
包括 fuzzy 翻译 到编译文件。
使用实例：
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
运行你的 ENGINE 配置中指定的数据库引擎的命令行客户端，连接参数在你的 USER、 PASSWORD 等配置中指定。
对于 PostgreSQL 来说，这将运行 psql 命令行客户端。
对于 MySQL 来说，这将运行 mysql 命令行客户端。
对于 SQLite 来说，这将运行 sqlite3 命令行客户端。
对于 Oracle 来说，这将运行 sqlplus 命令行客户端。
这个命令假设程序在你的 PATH 上，这样调用程序名（psql、mysql、sqlite3、sqlplus）就能在正确的地方找到程序。没有办法手动指定程序的位置。
--database DATABASE
指定打开命令行的数据库。默认为 default。
-- ARGUMENTS
-- 分界线后的任何参数都会被传递给底层的命令行客户端。例如，对于 PostgreSQL，你可以使用 psql 命令的 -c 标志直接执行一个原始 SQL 查询：
$ django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
显示当前设置文件与 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 的结果被保存为一个文件时，它可以作为 fixture 用于 tests 或作为 initial data。
注意 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
从数据库中删除所有数据，并重新执行任何同步后处理程序。已应用迁移的表不会被清除。
如果你更愿意从一个空的数据库开始，并重新运行所有迁移，你应该删除并重新创建数据库，然后运行 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 是其默认值）。
特定于数据库的注释
Oracle
如果使用 --includ-views，则会为物化视图创建模型。
PostgreSQL
为外部表创建模型。
如果使用 --includ-views，则会为物化视图创建模型。
如果使用 --include-partitions，则为分区表创建模型。
--database DATABASE
指定要检查的数据库。默认为 default。
--include-partitions
如果提供了这个选项，也会为分区创建模型。
只实现了对 PostgreSQL 的支持。
--include-views
如果提供了这个选项，也会为数据库视图创建模型。
排除从给定的应用程序和／或模型加载固定数据（以 app_label 或 app_label.ModelName 的形式）。多次使用该选项以排除一个以上的应用程序或模型。
从 stdin 加载固定数据
你可以使用短横线作为 fixture 名称来加载来自 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 -
dumpdata 命令可以用来生成 loaddata 的输入。
有关 fixture 的更多详细信息，请参阅 辅助工具 主题。
遍历当前目录下的整个源码树，并提取所有标记为翻译的字符串，并在 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
使用实例：
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
根据检测到的模型变化创建新的迁移。迁移，它们与应用程序的关系以及更多的内容在 迁移文档 中深入介绍。
提供一个或多个应用名称作为参数，将把创建的迁移限制在指定的应用和任何所需的依赖关系上（例如，ForeignKey 的另一端的表）。
要将迁移添加到没有 migrations 目录的应用中，运行 makemigrations，并使用应用的 app_label。
--noinput, --no-input
压制所有用户提示。如果不能自动解决被抑制的提示，命令将以 error code 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 来回溯所有的迁移，即恢复一个应用的所有已应用迁移。
当取消应用迁移时，所有依赖的迁移也将被取消应用，无论 <app_label>。你可以使用 --plan 来检查哪些迁移将被取消应用。
--database DATABASE
指定要迁移的数据库。默认值为 default。
--fake
标记目标的迁移（按照上面的规则）已应用，但没有实际运行 SQL 来改变你的数据库架构。
这是为高级用户准备的，如果他们要手动应用更改，可以直接操作当前的迁移状态；要注意的是，使用 --fake 会有将迁移状态表置于需要手动恢复才能使迁移正确运行的状态的风险。
--fake-initial
允许 Django 在迁移中所有 CreateModel 操作创建的所有模型名称的数据库表已经存在的情况下，跳过应用的初始迁移。这个选项是为了在第一次针对一个在使用 migrations 之前就存在的数据库运行迁移时使用。但是，除了匹配表名之外，这个选项并不检查数据库架构是否匹配，因此只有当你确信你现有的架构与初始迁移中记录的内容相匹配时，才可以安全使用。
--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]
在本地机器上启动一个轻量级的开发网络服务器。默认情况下，该服务器在 IP 地址 127.0.0.1 的 8000 端口上运行。你可以明确地传递一个 IP 地址和端口号。
如果你以普通用户的身份运行这个脚本 (推荐)， 你可能无法在低端口号上启动一个端口。低端口号是为超级用户（root）保留的。
本服务器使用 WSGI_APPLICATION 配置中指定的 WSGI 应用对象。
DO NOT USE THIS SERVER IN A PRODUCTION SETTING.
This lightweight development server has not gone through security audits or
performance tests, hence is unsuitable for production. Making this server
able to handle a production environment is outside the scope of Django.
开发服务器会根据需要为每个请求自动重新加载 Python 代码。你不需要重新启动服务器以使代码更改生效。然而，有些操作，如添加文件不会触发重启，所以在这些情况下你必须重启服务器。
如果你在 Linux 或 MacOS 上安装了 pywatchman 和 Watchman 服务，那么将使用内核信号来自动重新加载服务器（而不是每秒轮询文件修改时间戳）。这在大型项目上提供了更好的性能，在代码更改后减少了响应时间，更强大的更改检测以及减少了电力消耗。Django 支持 pywatchman 1.2.0 及更高版本。
有许多文件的大目录可能会导致性能问题。
当使用 Watchman 时，如果项目中包含大的非 Python 目录，比如 node_modules，建议忽略这个目录以获得最佳性能。关于如何做到这一点，请参见 watchman文档 。
Watchman 超时
DJANGO_WATCHMAN_TIMEOUT
Watchman 客户端的默认超时时间是 5 秒。你可以通过设置 DJANGO_WATCHMAN_TIMEOUT 环境变量来改变它。
当你启动服务器时，以及每次在服务器运行时修改 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 应用被启用（新项目中的默认值）， runserver 命令将被它自己的 runserver 命令覆盖。
服务器的每个请求和响应的日志都会被发送到 django.server 日志器。
--noreload
禁用自动加载器。这意味着，如果特定的 Python 模块已经被加载到内存中，那么你在服务器运行时所做的任何 Python 代码更改将 不会 生效。
--nothreading
在开发服务器中禁止使用线程。默认情况下，服务器是多线程的。
--ipv6, -6
开发服务器使用 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 文件、图片、 MEDIA_URL 下的东西等等）。如果你想设置 Django 为服务静态媒体，请阅读 如何管理静态文件（如图片、JavaScript、CSS）。
在开发中使用 ASGI 进行服务
Django 的 runserver 命令提供了一个 WSGI 服务器。要在 ASGI 下运行，您需要使用一个 ASGI 服务器。Django Daphne 项目提供了 与 runserver 集成，您可以使用它。
sendtestemail
django-admin sendtestemail [email [email ...]]
发送一个测试邮件（以确认通过 Django 发送邮件是否正常工作）给指定的收件人。例如：
django-admin sendtestemail [email protected] [email protected]
有几个选项，你可以将它们任意组合在一起使用：
--managers
使用 mail_managers() 向 MANAGERS 中指定的邮件地址发送邮件。
--admins
使用 mail_admins() 向 ADMINS 中指定的邮件地址发送邮件。
shell
django-admin shell
启动 Python 交互式解释器。
--interface {ipython,bpython,python}, -i {ipython,bpython,python}
指定要使用的命令行。默认情况下，Django 会使用安装了的 IPython 或 bpython 。如果两者都安装了，请指定使用哪一个：
IPython:
django-admin shell -i ipython
bpython:
django-admin shell -i bpython
如果你安装了一个 "rich" shell 但想要强制使用 "plain" Python 解释器，请使用 python 作为接口名称，如下所示：
django-admin shell -i python
允许你将一个命令作为字符串传递，以便像这样作为 Django 执行它：
django-admin shell --command="import django; print(django.__version__)"
你也可以在标准输入上传入代码来执行。例如：
$ django-admin shell <<EOF
> import django
> print(django.__version__)
在 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，它将修复序列与其自动递增的字段数据不同步的情况。
--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 的 bug 报告来说明这个行为，因为优化的目的是为了安全。
--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
提供指向自定义应用模板文件目录的路径，或指向未压缩档案（.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
指定除了 .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'。
当应用模板文件用 Django 模板引擎渲染时（默认是所有 *.py 文件），Django 也会替换掉所有包含的游离模板变量。例如，如果其中一个 Python 文件中包含了解释与模板渲染相关的特定功能的 docstring，可能会导致一个错误的例子。
为了解决这个问题，你可以使用 templatetag 模板标签来”转义“模板语法的各个部分。
此外，为了允许包含 Django 模板语言语法的 Python 模板文件，同时也为了防止打包系统试图对无效的 *.py 文件进行字节编译，以 .py-tpl 结尾的模板文件将改名为 .py。
在使用自定义应用程序（或项目）模板之前，应始终审查其内容：这些模板定义了将成为项目一部分的代码，这意味着这些代码将被视为你安装的任何应用程序或自己编写的代码一样可信。此外，甚至渲染模板实际上是执行作为管理命令输入提供的代码。Django 模板语言可能会为系统提供广泛的访问权限，因此请确保你使用的任何自定义模板值得信任。
startproject
django-admin startproject name [directory]
在当前目录或给定的目标目录中为给定的项目名称创建一个 Django 项目目录结构。
默认情况下，新目录 包含 manage.py 和一个项目包（包含 settings.py 和其他文件）。
如果只给出项目名称，则项目目录和项目包都将命名为 <projectname>，并在当前工作目录下创建项目目录。
如果提供了可选的目的地，Django 将使用该已有目录作为项目目录，并在其中创建 manage.py 和项目包。用 '.' 表示当前的工作目录。
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
指定除了 .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
压制所有用户提示。一个典型的提示是关于删除现有测试数据库的警告。
测试运行器选项
test 命令代表指定的 --testrunner 接收选项。这些是默认测试运行器的选项： DiscoverRunner。
--keepdb
在测试运行之间保留测试数据库。这样做的好处是可以跳过创建和销毁这两个动作，从而大大缩短测试运行的时间，尤其是在大型测试套件中。如果测试数据库不存在，将在第一次运行时创建，然后在以后的每次运行中保留。除非 MIGRATE 测试配置为 False，否则任何未应用的迁移也会在运行测试套件之前应用到测试数据库。
--shuffle [SEED]
在运行测试之前，随机化测试的顺序。这可以帮助发现那些没有正确隔离的测试。这个选项产生的测试顺序是给定的整数种子的一个确定性函数。当没有传递种子时，会随机选择一个种子并打印到控制台。要重复一个特定的测试顺序，需要传递一个种子。这个选项生成的测试顺序保留了 Django 的 测试顺序的保证。它们还保持了测试案例类别的测试分组。
在缩小隔离问题时，洗牌后的顺序也有一个特殊的一致性属性。也就是说，对于一个给定的种子，当运行一个测试子集时，新的顺序将是限制在较小的集合上的原始洗牌。同样地，在保持种子不变的情况下增加测试时，原始测试的顺序在新的顺序中也是一样的。
--reverse, -r
将测试案例以相反的执行顺序排序。这可能有助于调试没有正确隔离的测试的副作用。 按测试类别分组 在使用此选项时被保留下来。这可以和 --shuffle 一起使用，以扭转特定种子的顺序。
--debug-mode
在运行测试之前，将 DEBUG 设置为 True。这可能有助于解决测试失败的问题。
--debug-sql, -d
对失败的测试启用 SQL 日志。如果 --verbosity 是 2，那么通过测试的查询也会被输出。
--parallel [N]
在单独的并行进程中运行测试。由于现代处理器拥有多个内核，这使得运行测试的速度大大加快。
使用 --parallel 不加值，或使用 auto 值，根据 multiprocessing.cpu_count() 每个核心运行一个测试进程。你可以通过传递所需的进程数来覆盖这一点，例如：--parallel 4，或者通过设置 DJANGO_TEST_PROCESSES 环境变量。
Django 将测试用例（unittest.TestCase 子类）分发给子进程。如果测试用例类的数量少于配置的进程数量，Django 将相应地减少进程数量。
每个进程都有自己的数据库。您必须确保不同的测试用例类不会访问相同的资源。例如，涉及文件系统的测试用例类应该为自己创建一个临时目录以供使用。
如果你有不能并行运行的测试类，你可以使用 SerializeMixin 按顺序运行它们。参见 强制按顺序运行测试类。
这个选项需要第三方的 tlib 包才能正确显示回溯。
$ python -m pip install tblib
这个功能在 Windows 上无法使用。它也不能与 Oracle 数据库后端一起工作。
如果你想在调试测试时使用 pdb，你必须禁用并行执行（-parallel=1）。如果不这样做，你会看到类似 bdb.BdbQuit 的东西。
当启用测试并行化后，测试失败时，Django 可能无法显示异常回溯。这可能会给调试带来困难。如果你遇到这个问题，请在不并行的情况下运行受影响的测试，以查看失败的回溯。
这是一个众所周知的限制。这是因为需要对对象进行序列化，以便在进程间进行交换。详见 What can be pickled and unpickled?。
--tag TAGS
只运行 特定标签标记 的测试。可多次指定，并与 test --exclud-tag 结合使用。
未能加载的测试总是被认为是匹配的。
--exclude-tag EXCLUDE_TAGS
不包括 特定标签标记的 测试。可多次指定，并与 test --tag 结合使用。
-k TEST_NAME_PATTERNS
运行与测试名称模式相匹配的测试方法和类，与 unittest's -k option 一样。可以指定多次。
--pdb
在每次测试错误或失败时，都会产生一个 pdb 调试器。如果你安装了 ipdb，则使用其代替。
--buffer, -b
丢弃通过测试的输出（stdout 和 stderr），与 unittest's --buffer option 一样。
--no-faulthandler
Django 在启动测试时自动调用 faulthandler.enable()，这允许它在解释器崩溃时打印一个回溯信息。传递 --no-faulthandler 来禁止这种行为。
--timing
输出时间，包括数据库设置和总运行时间。
--durations N
New in Django 5.0.
显示 N 个最慢的测试用例（当 N=0 时显示所有）。
Python 3.12 及以后版本
此功能仅适用于 Python 3.12 及更高版本。
按照 测试数据库 中的描述，创建一个测试数据库。
用给定固定数据的数据填充测试数据库。关于固定数据的更多信息，请参见上面的 loaddata 的文档）。
运行 Django 开发服务器（如 runserver），指向这个新创建的测试数据库，而不是你的生产数据库。
这在很多方面都很有用：
当你在写 单元测试 时，你的视图如何与某些固定数据一起行动，你可以使用 testserver 在网络浏览器中手动与视图互动。
假设你正在开发你的 Django 应用程序，并且有一个“原始”的数据库副本，你想要与之交互。你可以将数据库转储为一个 fixture （使用上面介绍的 dumpdata 命令），然后使用 testserver 运行你的 Web 应用程序，并使用那些数据。通过这种安排，你可以灵活地对数据进行任何更改，因为你知道你所做的任何数据更改只会影响测试数据库。
请注意，这个服务器 不会 自动检测你的 Python 源代码的变化（就像 srunerver 那样)。但是，它可以检测到对模板的更改。
--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 fixture：
django-admin testserver --addrport 1.2.3.4:7000 test
只有安装了 Django 的 认证系统 （django.contrib.auth），这个命令才有效。
允许更改用户的密码。它提示你为给定的用户输入两次新密码。如果输入的密码相同，则立即成为新密码。如果你没有提供用户，命令将尝试更改与当前用户用户名匹配的密码。
--database DATABASE
指定要为用户查询的数据库。默认为 default。
使用实例：
django-admin changepassword ringo
只有安装了 Django 的
