# Django 6.0.7 documentation

# 系统检查框架

系统检查框架是一套用于验证 Django 项目的静态检查。它检测常见的问题，并提供如何修复这些问题的提示。该框架是可扩展的，所以你可以很容易地添加自己的检查。

关于如何添加自己的检查并与 Django 的系统检查集成的细节，请看 系统检查主题指南。

## API 参考

### `CheckMessage`

class CheckMessage(level, msg, hint=None, obj=None, id=None)

  系统检查提出的警告和错误必须是 `CheckMessage` 的实例。一个实例封装了一个单一的可报告的错误或警告。它还提供适用于该信息的上下文和提示，以及用于过滤目的的唯一标识符。

  构造方法的参数：

  `level`

    The severity of the message. Use one of the predefined values: `DEBUG` , `INFO`, `WARNING`, `ERROR`, `CRITICAL`. If the level is greater or equal to `ERROR`, then Django will prevent management commands from executing. Messages with level lower than `ERROR` (i.e. warnings) are reported to the console, but can be silenced.

  `msg`

    描述问题的简短（少于 80 个字符）字符串。该字符串 不应 包含换行符。

  `hint`

    一个单行字符串，提供解决问题的提示。如果不能提供任何提示，或者提示是错误信息中不言自明的，可以省略提示，或者使用 `None` 值。

  `obj`

    可选的。为信息提供上下文的对象（例如，发现问题的模型）。该对象应该是一个模型、字段、管理器或定义了 `str__()` 方法的任何其他对象。该方法在报告所有消息时使用，其结果在消息之前。

  `id`

    可选字符串。问题的唯一标识符。标识符应遵循 `applabel.X001` 的模式，其中 `X` 是字母 `CEWID` 中的一个，表示消息的严重性（`C` 表示严重，`E` 表示错误等）。这个数字可由应用程序分配，但在该应用程序内应是唯一的。

有一些子类可以使创建具有通用级别的消息更容易。当使用它们时，你可以省略 `level` 参数，因为它已被类名所隐含。

class Debug(msg, hint=None, obj=None, id=None)

class Info(msg, hint=None, obj=None, id=None)

class Warning(msg, hint=None, obj=None, id=None)

class Error(msg, hint=None, obj=None, id=None)

class Critical(msg, hint=None, obj=None, id=None)

## 内置标签

Django 的系统检查按以下标签组织：

- `admin`：检查所有管理站点的声明。

- `async_support`： 检查异步相关配置。

- `caches`：检查缓存相关的配置。

- `compatibility`：标记版本升级可能导致的问题。

- `commands`: Checks custom management commands related configuration.

- `database`: Checks database-related configuration issues. Database checks are not run by default because they do more than only static code analysis as most regular checks do. They are only run by the `migrate` command or if you specify configured database aliases using the `--database` option when calling the `check` command.

- `files` ：检查文件的相关配置。

- `mail`: Checks email related configuration.

- `models`：检查模型、字段和管理器定义。

- `security`：检查安全相关配置。

- `signals`：检查信号声明和处理器注册信息。

- `sites` ： 检查 `django.contrib.sites` 配置。

- `staticfiles`：检查 `django.contrib.staticfiles` 配置。

- `templates`：检查模板相关配置。

- `translation`：检查翻译相关配置。

- `urls`：检查 URL 配置。

一些可能通过多个标签同时注册的检查项。

## 核心系统检查

### 异步支持

以下检查验证了你对 异步支持 的配置：

- async.E001：你在部署时不应该设置 `DJANGO_ALLOW_ASYNC_UNSAFE` 环境变量。这将禁用 异步安全保护。

### 向后兼容

兼容性检查警告那些升级 Django 后可能出现的问题。

- 2_0.W001：你的 URL 模式 `<pattern>` 有一个 `route` 包含 `(?P<`、以 `^` 开始或以 `$` 结束。这可能是在从 `url()` 迁移到 `path()` 时的一个疏忽。

- 4_0.E001:从Django 4.0开始， `CSRF_TRUSTED_ORIGINS`设置中的值必须以一个形式开始（通常是``http://`或``https://`），但发现了``<hostname>``。

### 缓存

以下检查验证你的 `CACHES` 配置是否正确设置：

- caches.E001：你必须在你的 `CACHES` 配置中定义一个 `'default'` 缓存。

- caches.W002 ：你的 `<cache>` 配置可能会暴露你的缓存或导致你的数据损坏，因为它的 `LOCATION` 匹配／是在／包含 `MEDIA_ROOT` ／ `STATIC_ROOT` ／ `STATICFILES_DIRS`。

- caches.W003 ： 你的 `<cache>` 缓存 `LOCATION` 是相对路径。请使用绝对路径。

### 数据库

#### MySQL 和 MariaDB

如果你使用的是 MySQL 或 MariaDB，将执行以下检查：

- mysql.E001：MySQL／MariaDB 不允许有唯一约束的 `CharField` 有一个 `max_length` > 255。这项检查在 Django 3.1 中 被改为 `mysql.W003`，因为真正的最大尺寸取决于许多因素。

- mysql.W002：MySQL／MariaDB 数据库连接 `<alias>` 未设置为严格模式。另见 设置 sql_mode。

- mysql.W003：MySQL／MariaDB 不允许有唯一约束的 `CharField` 有 `max_length` > 255。

### Mail

The following checks verify that your `MAILERS` setting is correctly configured:

- mail.E001: Your `MAILERS` setting uses a development-only email backend in the `'default'` entry (`<backend>`). (Only checked when the `check --deploy` option is used.)

- mail.W001: Your `MAILERS` setting has no `'default'` entry. Sending email without a valid mailer will fail.

### 管理文件

以下检查验证了你对 管理文件 的配置：

- files.E001: `FILE_UPLOAD_TEMP_DIR` 设置引用了不存在的目录 `<path>`。

### 模型字段

- fields.E001：字段名不能以下划线结尾。

- fields.E002：字段名不能有 `"__"`。

- fields.E003：`pk` 是保留关键字，不能作为字段名使用。

- fields.E004: `choices` must be a mapping (e.g. a dictionary) or an ordered iterable (e.g. a list or tuple, but not a set).

- fields.E005: `choices` 必须是一个将实际值映射到人类可读名称的映射，或者是一个包含 `(实际值, 人类可读名称)` 元组的可迭代对象。

- fields.E006：`db_index` 必须是 `None`，`True` 或 `False`。

- fields.E007：主键不能有 `null = True`。

- fields.E008：所有 `validators` 必须都是可调用的。

- fields.E009：`max_length` 太小，无法容纳 `choices` 中的最长值（`<count>` 字符）。

- fields.E010：`<field>` 默认值应该是一个可调用对象，而不是一个实例，这样就不会在所有字段实例之间共享。

- fields.E011: `<database>` 不支持具有表达式（`db_default`）的默认数据库值。

- fields.E012: 无法在 `db_default` 中使用 `<expression>`。

- fields.E013: `CompositePrimaryKey` must be named `pk`.

- fields.E100： `AutoField` 必须设置 primary_key=True。

- fields.E110：`BooleanField` 不接受空值。这项检查出现在 Django 2.1 中增加对空值的支持之前。

- fields.E120： `CharField` 必须定义一个 `max_length` 属性。

- fields.E121： `max_length` 必须是个正整数。

- fields.W122： `max_length` 在使用 `<integer field type>` 时会被忽略。

- fields.E130： `DecimalField` 必须定义一个 `decimal_places` 属性。

- fields.E131： `decimal_places` 必须是个非负整数。

- fields.E132： `DecimalField` 必须定义一个 `max_digits` 属性。

- fields.E133：`max_digits` 必须是一个正整数。

- fields.E134： `max_digits` 必须大于或等于 `decimal_places`。

- fields.E135: `DecimalField`’s `max_digits` and `decimal_places` must both be defined or both omitted.

- fields.E140： `FilePathField` 的 `allow_files` 或 `allow_folders` 必须有一个被设为 True。

- fields.E150: 如果 `null=False`，则 `GenericIPAddressField` 不能具有 `blank=True`，因为空值将存储为 null 值。

- fields.E160：`auto_now`、`auto_now_add` 和 `default` 等选项是相互排斥的。这些选项只能有一个。

- fields.W161：提供了固定的默认值。

- fields.W162： `<database>` 并不支持在 `<field data type>` 列上创建数据库索引。

- fields.W163: `<database>` 不支持在列上添加注释（`db_comment`）。

- fields.E170：`BinaryField` 的 `default` 不能是字符串。使用字节内容代替。

- fields.E180：`<database>` 不支持 `JSONField`。

- fields.E190 ： `<database>` 不支持对 `<field_type>` 进行字符序设置。

- fields.E220: `<database>` 不支持 `GeneratedField`。

- fields.E221: `<database>` 不支持非持久化的 `GeneratedField`。

- fields.E222: `<database>` 不支持持久化的 `GeneratedField`。

- fields.E223: `GeneratedField.output_field` 存在错误：...

- fields.W224: `GeneratedField.output_field` 存在警告：...

- fields.W225: `null` has no effect on `GeneratedField`.

- fields.E900：`IPAddressField` 已被删除，但历史迁移中的支持除外。

- fields.W900：`IPAddressField` 已被废弃。在 Django 1.9 中，将取消对它的支持（除了历史迁移）。这个检查出现在 Django 1.7 和 1.8 中。

- fields.W901：`CommaSeparatedIntegerField` 已被废弃。在 Django 2.0 中，对它的支持将被删除（除了在历史迁移中）。这个检查出现在 Django 1.10 和 1.11 中。

- fields.E901：`CommaSeparatedIntegerField` 已被删除，但历史迁移中的支持除外。

- fields.W902：`FloatRangeField` 已被废弃，将在 Django 3.1 中删除。这项检查出现在 Django 2.2 和 3.0 中。

- fields.W903: `NullBooleanField` 已被弃用。除了在历史迁移中的支持外，在 Django 4.0 中将会移除对它的支持。此检查出现在 Django 3.1 和 3.2 中。

- fields.E903：“NullBooleanField” 已被删除，但历史迁移中的支持除外。

- fields.W904: `django.contrib.postgres.fields.JSONField` 已被弃用。（除了在历史迁移中的支持外）在 Django 4.0 中将会移除对它的支持。此检查出现在 Django 3.1 和 3.2 中。

- fields.E904: `django.contrib.postgres.fields.JSONField` 已被移除，除了在历史迁移中的支持外。

- fields.W905: `django.contrib.postgres.fields.CICharField` 已弃用。对其的支持（除了在历史迁移中）将在 Django 5.1 中移除。此检查出现在 Django 4.2 和 5.0 中。

- fields.E905: `django.contrib.postgres.fields.CICharField` 已被移除，仅在历史迁移中保留支持。

- fields.W906: `django.contrib.postgres.fields.CIEmailField` 已弃用。对其的支持（除了在历史迁移中）将在 Django 5.1 中移除。此检查出现在 Django 4.2 和 5.0 中。

- fields.E906: `django.contrib.postgres.fields.CIEmailField` 已被移除，仅在历史迁移中保留支持。

- fields.W907: `django.contrib.postgres.fields.CITextField` 已弃用。对其的支持（除了在历史迁移中）将在 Django 5.1 中移除。此检查出现在 Django 4.2 和 5.0 中。

- fields.E907: `django.contrib.postgres.fields.CITextField` 已被移除，仅在历史迁移中保留支持。

#### 文件字段

- fields.E200：`unique` 不是 `FileField` 的有效参数。这项检查在 Django 1.11 中已被删除。

- fields.E201： `primary_key` 对于 `FileField` 来说不是个有效的参数。

- fields.E202： `FileField` 的 `upload_to` 参数必须是个相对路径，而不是一个相对路径。

- fields.E210： 不能使用 `ImageField`，因为未安装 Pillow。

#### 关联字段

- fields.E300：字段定义了与模型 ``<model>``的关系，该模型要么没有安装，要么是抽象的。

- fields.E301 ： 字段定义了一个与 `<app_label>.<model>` 模型的关系，该模型已被替换。

- fields.E302: 反向访问器 `<related model>.<accessor name>` 与字段名 `<app_label>.<model>.<field name>` 冲突。

- fields.E303: 反向查询名称与字段名 `<app_label>.<model>.<field name>` 冲突。

- fields.E304: 反向访问器 `<related model>.<accessor name>` 与反向访问器 `<app_label>.<model>.<field name>` 冲突。

- fields.E305: 反向查询名称与反向查询名称 `<app_label>.<model>.<field name>` 冲突。

- fields.E306: 名称 `<name>` 对于字段 `<model>.<field name>` 的 `related_name` 是无效的。

- fields.E307：字段 `<app label>.<model>.<field name>` 被声明为对 `<app label>.<model>` 的惰性引用，但应用程序 `<app label>` 没有安装或没有提供模型 `<model>`。

- fields.E308：反向查询名称 `<related query name>`，不得以下划线结束。

- fields.E309：逆向查询名称 `<related query name>`，不得包含 `'__'`。

- fields.E310：模型 `<model>` 上的 `<field1>`、`<field2>` 等字段的子集没有唯一性。

- fields.E311：`<model>.<field name>` 必须是唯一的，因为它是由 `ForeignKey` 引用的。

- fields.E312：`to_field` `<field name>` 在相关模型 `<app label>.<model>` 上不存在。

- fields.E320: Field specifies `on_delete=<set null option>`, but cannot be null.

- fields.E321: Field specifies `on_delete=SET_DEFAULT`, but has no `default` value.

- fields.E322: Field specifies `on_delete=DB_SET_DEFAULT`, but has no `db_default` value.

- fields.E323: Field specifies database/Python-level on_delete variant, but referenced model uses python/database-level variant.

- fields.E324: `<database>` does not support `<database delete option>`.

- fields.E330：`ManyToManyField` 不能是唯一的。

- fields.E331：字段通过模型 `<model>` 具体说明多对多关系，该模型尚未安装。

- fields.E332：有中间表的多对多字段不得对称。 这项检查是在 Django 3.0 之前出现的 。

- fields.E333：该模型被 `<model>` 用作中间模型，但它有两个以上的外键到 `<model>`，这是不明确的。你必须通过 `through_fields` 关键字参数指定 Django 应该使用哪两个外键。

- fields.E334：该模型被 `<model>` 用作中间模型，但它有一个以上来自 `<model>` 的外键，这是不明确的。你必须通过 `through_fields` 关键字参数指定 Django 应该使用哪个外键。

- fields.E335：该模型被 `<model>` 用作中间模型，但它有一个以上的 `<model>` 外键，这是不明确的。你必须通过 `through_fields` 关键字参数指定 Django 应该使用哪个外键。

- fields.E336：该模型被 `<model>` 用作中介模型，但它没有 `<model>` 或 `<model>` 的外键。

- fields.E337：字段规定了 `through_fields`，但没有提供应通过 `<model>` 用于关系的两个链接字段的名称。

- fields.E338：中间模型 `<through model>`，没有字段 `<field name>`。

- fields.E339：`<model>.<field name>` 不是 `<model>` 的外键。

- fields.E340：该字段的中间表 `<table name>` 与表名 `<model>`/`<model>.<field name>` 相冲突。

- fields.W340：`null` 对 `ManyToManyField` 没有影响。

- fields.W341：`ManyToManyField` 不支持 `validators`。

- fields.W342：对 `ForeignKey` 设置 `unique=True` 与使用 `OneToOneField` 效果相同。

- fields.W343: 在具有 `through` 模型的 `ManyToManyField` 上，`limit_choices_to` 不起作用。此检查在 Django 4.0 之前出现。

- **fields.W344*：该字段的中间表 `<table name>` 与表名 `<model>`/``<model>.<field name>``相冲突。

- fields.W345: 在具有对称关系的 `ManyToManyField` 上，例如对 "self"，`related_name` 不起作用。

- fields.W346: `db_comment` 在 `ManyToManyField` 上无效。

- fields.E347: Field defines a relation involving model `<model>` which has a `CompositePrimaryKey` and such relations are not supported.

- fields.E348: Related name `<related_name>` for `<model>.<field name>` clashes with the name of a model manager.

### 模型

- models.E001： `<swappable>` 不是表单 `app_label.app_name`。

- models.E002：`<SETTING>` 引用了 `<model>`，但该网站尚未安装，或者是抽象的。

- models.E003：该模型通过中间模型 `<app_label>.<model>` 有两个相同的多对多关系。

- models.E004：`id` 只有在字段也设置了 `primary_key=True` 的情况下才能用作字段名。

- models.E005：父模型 `<model>` 中的字段 `<field name>` 与父模型 `<model>` 中的字段 `<field name>` 发生冲突。

- models.E006: 字段 `<field name>` 与模型 `<model>` 中的字段 `<field name>` 冲突。

- models.E007： 列名 `<column name>` 被其它字段使用的字段 `<field name>` 。

- models.E008: `index_together` 必须是一个列表或元组。此检查在 Django 5.1 之前就已存在。

- models.E009: 所有 `index_together` 元素必须是列表或元组。此检查在 Django 5.1 之前就已存在。

- models.E010： `unique_together` 必须是个列表或元组。

- models.E011： 所有 `unique_together` 元素都必须是列表或元组。

- models.E012: `constraints/indexes/unique_together` 引用了不存在的字段 `<field name>`。

- models.E013: `constraints/indexes/unique_together` 引用了 `ManyToManyField` `<field name>`，但 `ManyToManyField` 不支持该选项。

- models.E014： `ordering` 必须是个元组或列表（即便你只想按照一个字段进行排序）。

- models.E015：`ordering` 指向是不存在的字段、相关字段或查找 `<field name>`。

- models.E016: `constraints/indexes/unique_together` 引用了字段 `<field_name>`，但该字段不属于模型 `<model>`。

- models.E017：代理模型 `<model>`，包含模型字段。

- models.E018：自动生成的列名对字段 `<field>` 来说太长。数据库 `<alias>` 的最大长度为 `<maximum length>`。

- models.E019：自动生成的列名对 M2M 字段 `<M2M field>` 来说太长。数据库 `<alias>` 的最大长度为 `<maximum length>`。

- models.E020：`<model>.check()` 类方法目前被覆盖。

- models.E021：`ordering` 和 `order_with_respect_to` 不能一起使用。

- models.E022：`<function>` 包含对 `<app label>.<model>` 的惰性引用，但应用 `<app label>` 没有安装或没有提供模型 `<model>`。

- models.E023：模型名称 `<model>` 不能以下划线开头或结尾，因为它与查找语法相冲突。

- models.E024：模型名称 `<model>` 不能包含双下划线，因为它与查找语法相冲突。

- models.E025：`<property name>` 属性与相关字段存取器发生冲突。

- models.E026：该模型不能有一个以上的 `primary_key=True` 字段。

- models.W027：`<database>` 不支持检查约束。

- models.E028：`db_table` `<db_table>` 被多个模型使用：`<model list>`。

- models.E029：索引名 `<index>` 对模型 `<model>` 不是唯一的。

- models.E030 ：索引名 `<index>` 在模型 `<model list>` 中不是唯一的。

- models.E031：约束名称 `<constraint>` 对模型 `<model>` 不是唯一的。

- models.E032 ： 约束名称 `<constraint>` 在模型 `<model list>` 中不是唯一的。

- models.E033：索引名称 `<index>` 不能以下划线或数字开头。

- models.E034：索引名称 `<index>` 不能长于 `<max_length>` 字符。

- models.W035：`db_table` `<db_table>` 被多个模型使用：`<model list>`。

- models.W036：`<database>` 不支持带有条件的唯一约束。

- models.W037：`<database>` 不支持有条件的索引。

- models.W038：`<database>` 不支持可推迟的唯一约束。

- models.W039 ： `<database>` 不支持非键列的唯一约束。

- models.W040 ： `<database>` 不支持带有非键列的索引。

- models.E041 ： `constraints` 指向 join 字段 `<field name>`。

- models.E042: `<field name>` cannot be included in the composite primary key.

- models.W042: Auto-created primary key used when not defining a primary key type, by default `django.db.models.AutoField`. This check appeared in Django 3.2 - 5.2.

- models.W043 ： `<database>` 不支持对表达式的索引。

- models.W044: `<database>` 不支持在表达式上的唯一约束。

- models.W045: 检查约束 `<constraint>` 包含 `RawSQL()` 表达式，并且在模型的 `full_clean()` 中不会得到验证。

- models.W046: `<database>` 不支持在表上添加注释（`db_table_comment`）。

- models.W047: `<database>` does not support `UniqueConstraint.nulls_distinct`.

- models.E048: `constraints/indexes/unique_together` refers to a `CompositePrimaryKey` `<field name>`, but `CompositePrimaryKey`s are not supported for that option.

- models.E049: `constraints/indexes/unique_together` refers to a `ForeignObject` `<field name>` with multiple `from_fields`, which is not supported for that option.

- models.E050: The model cannot have related fields with both database-level and Python-level `on_delete` variants.

### 管理命令

The following checks verify custom management commands are correctly configured:

- commands.E001: The `migrate` and `makemigrations` commands must have the same `autodetector`.

### 安全

安全检查并不能使你的网站安全。它们不会审计代码，进行入侵检测，或做任何特别复杂的事情。相反，它们有助于执行一个自动化的、唾手可得的检查清单，可以帮助你提高网站的安全性。

其中一些检查可能不适合你的特定部署配置。例如，如果你在负载均衡器中进行 HTTP 到 HTTPS 的重定向，那么不断地被警告没有启用 `SECURE_SSL_REDIRECT` 会很恼火。使用 `SILENCED_SYSTEM_CHECKS` 来关闭不需要的检查。

如果使用 `check --deploy` 选项，则会运行以下检查：

- security.W001: 你的 `MIDDLEWARE` 中没有包含 `django.middleware.security.SecurityMiddleware`，因此 `SECURE_HSTS_SECONDS`、`SECURE_CONTENT_TYPE_NOSNIFF`、`SECURE_REFERRER_POLICY`、`SECURE_CROSS_ORIGIN_OPENER_POLICY` 和 `SECURE_SSL_REDIRECT` 设置将不会生效。

- security.W002：你的 `MIDDLEWARE` 中没有 `django.middleware.clickjacking.XFrameOptionsMiddleware`，因此你的页面不会使用 `'x-frame-options'` 头。除非有很好的理由让你的网站以框架形式提供服务，否则你应该考虑启用这个头以帮助防止点击劫持攻击。

- security.W003：你似乎没有通过中间件使用 Django 内置的跨站请求伪造保护功能（`django.middleware.csrf.CsrfViewMiddleware` 不在你的 `MIDDLEWARE` 中）。启用中间件是最安全的方法，以确保你不会留下任何漏洞。

- security.W004：你没有为 `SECURE_HSTS_SECONDS` 配置设置一个值。如果你的整个网站只通过 SSL 提供服务，你可能需要考虑设置一个值并启用 HTTP 严格传输安全。一定要先阅读文档，不小心启用 HSTS 会导致严重的、不可逆转的问题

- security.W005：你没有将 `SECURE_HSTS_INCLUDE_SUBDOMAINS` 设置为 `True`。如果没有这个设置，你的网站就有可能受到通过不安全连接到子域的攻击。只有当你确定你的域名的所有子域都应该只通过 SSL 来提供服务时，才将此设置为 `True`。

- security.W006：你的 `SECURE_CONTENT_TYPE_NOSNIFF` 配置没有设置为 `True`，因此你的网页不会以 `'X-Content-Type-Options: nosniff'` 头提供服务。你应该考虑启用这个头，以防止浏览器错误地识别内容类型。

- security.W007: 你的 `SECURE_BROWSER_XSS_FILTER` 设置没有被设置为 `True`，因此你的页面将不会包含 `'X-XSS-Protection: 1; mode=block'` 头部。你应该考虑启用这个头部以激活浏览器的 XSS 过滤，以帮助防止 XSS 攻击。这个检查在 Django 3.0 中被移除，因为现代浏览器不再支持``X-XSS-Protection`` 头部。

- security.W008：你的 `SECURE_SSL_REDIRECT` 配置没有设置为 `True`。除非你的网站需要通过 SSL 和非 SSL 连接，否则你可能需要将此设置设置为 `True`，或者配置一个负载平衡器或反向代理服务器，将所有连接重定向到 HTTPS。

- security.W009: 你的 `SECRET_KEY` 字符串长度小于 50 个字符，包含少于 5 个不同字符，或以 `'django-insecure-'` 为前缀，表明它是由 Django 自动生成的。请生成一个长且随机的值，否则 Django 的许多安全关键功能将容易受到攻击。

- security.W010：你的 `INSTALLED_APPS` 中有 `django.contrib.session`，但你没有将 `SESSION_COOKIE_SECURE` 设置为 `True`。使用仅安全的会话 cookie 可以使网络流量嗅探器更难劫持用户会话。

- security.W011：您的 `MIDDLEWARE` 中有 `django.contrib.session.middleware.SessionMiddleware`，但你没有将 `SESSION_COOKIE_SECURE` 设置为 `True`。使用仅安全的会话 cookie 可以使网络流量嗅探器更难劫持用户会话

- security.W012：`SESSION_COOKIE_SECURE` 未设置为 `True`。使用仅安全的会话 cookie 使网络流量嗅探者更难劫持用户会话。

- security.W013：你的 `INSTALLED_APPS` 中有 `django.contrib.session`，但你没有将 `SESSION_COOKIE_HTTPONLY` 设置为 `True`。使用 `HttpOnly` 的会话 cookie 可以使跨站脚本攻击更难劫持用户会话。

- security.W014：你的 `MIDDLEWARE` 中有 `django.contrib.sessions.middleware.SessionMiddleware`，但你没有将 `SESSION_COOKIE_HTTPONLY` 设置为 `True`。使用 `HttpOnly` 的会话 cookie 可以使跨站脚本攻击更难劫持用户会话。

- security.W015：`SESSION_COOKIE_HTTPONLY` 未设置为 `True`。使用 `HttpOnly` 的会话 cookie 使跨站脚本攻击更难劫持用户会话。

- security.W016：`CSRF_COOKIE_SECURE` 未设置为 `True`。使用仅安全的 CSRF cookie 会使网络流量嗅探者更难窃取 CSRF 令牌。

- security.W017：`CSRF_COOKIE_HTTPONLY` 未设置为 `True`。使用 `HttpOnly` CSRF cookie 会使跨站脚本攻击更难窃取 CSRF 令牌。这个检查在 Django 1.11 中被删除了，因为 * :setting:`CSRF_COOKIE_HTTPONLY` * 配置没有实际的好处。

- security.W018：在部署时不应将 `DEBUG` 设置为 `True`。

- security.W019：在你的 `MIDDLEWARE` 中有 `django.middleware.clickjacking.XFrameOptionsMiddleware`，但 `X_FRAME_OPTIONS` 没有设置为 `'DENY'`。除非有很好的理由让你的网站在一个框架中为其他部分服务，否则你应该把它改为 `'DENY'`。

- security.W020：`ALLOWED_HOSTS` 在部署时不得为空。

- security.W021：你没有将 `SECURE_HSTS_PRELOAD` 设置为 `True`。否则，你的网站将无法提交到浏览器预加载列表。

- security.W022：你没有设置 `SECURE_REFERRER_POLICY` 配置。如果没有这个配置，你的网站将不会发送 Referrer-Policy 头。你应该考虑启用这个头以保护用户隐私。

- security.E023：你的 `SECURE_REFERRER_POLICY` 配置为无效值。

- security.E024: 你已将 `SECURE_CROSS_ORIGIN_OPENER_POLICY` 设置为无效值。

- security.W025: 你的 `SECRET_KEY_FALLBACKS[n]` 字符串长度小于 50 个字符，包含少于 5 个不同字符，或以 `'django-insecure-'` 为前缀，表明它是由 Django 自动生成的。请生成一个长且随机的值，否则 Django 的许多安全关键功能将容易受到攻击。

以下检查验证你的安全相关配置是否正确设置：

- security.E100: `DEFAULT_HASHING_ALGORITHM` 必须是 `'sha1'` 或 `'sha256'`。此检查出现在 Django 3.1 和 3.2 版本中。

- security.E101 ： CSRF 失败视图 `'path.to.view'` 没有使用正确的参数个数。

- security.E102 ： 无法导入 CSRF 失败视图 `'path.to.view'`。

- security.E026: The CSP setting `<SETTING_NAME>` must be a dictionary (got `<value>` instead).

- security.W027: Your Content Security Policy includes `CSP.NONCE` and `ContentSecurityPolicyMiddleware` is enabled, but `django.template.context_processors.csp` is not configured.

### 信号

- signals.E001：`<handler>` 与 `<signal>` 信号连接，并惰性引用发送方 `<app label>.<model>`，但应用 `<app label>` 没有安装或没有提供模型 `<model>`。

### 模板

以下检查验证你的 `TEMPLATES` 配置是否正确设置：

- templates.E001: 你在 `TEMPLATES` 中设置了 `'APP_DIRS': True`，但同时在 `OPTIONS` 中指定了 `'loaders'`。请移除 `APP_DIRS` 或移除 `'loaders'` 选项。此检查在 Django 5.1 中被移除，因为系统检查现在可能会抛出 `ImproperlyConfigured` 异常。

- templates.E002：`string_if_invalid` 在 `TEMPLATES` 的 `OPTIONS` 必须是一个字符串，但得到：`{value}` （`{type}`）。

- templates.E003: `<name>` 用于多个模板标签模块：`<module list>`。此检查在 Django 4.1.2 中更改为 `templates.W003`。

- templates.W003: `<name>` 用于多个模板标签模块：`<module list>`。

### 翻译

以下是对你的翻译配置进行的检查：

- translation.E001:：你为 `LANGUAGE_CODE` 设置提供了一个无效值 setting: `<value>`。

- translation.E002：你在 `LANGUAGES` 配置中提供了无效的语言代码 setting: `<value>`。

- translation.E003：你在 `LANGUAGES_BIDI` 设置中提供了一个无效的语言代码 setting: `<value>`。

- translation.E004：你为 `LANGUAGE_CODE` 配置提供了一个不在 `LANGUAGES` 配置中的值。

### URL

以下检查项针对你的 URL 配置执行：

- urls.W001：你的 URL 模式 `<pattern>` 使用 `include()`，并以 `$` 结尾的 `route`。把 `route` 中的美元符号去掉，以避免包含 URL 的问题。

- urls.W002：你的 URL 模式 `<pattern>` 有一个以 `/` 开头的 `route`。请删除这个斜线，因为它是不必要的。如果这个模式是以 `include()` 为目标，请确保 `include()` 模式有一个尾部的 `/`。

- urls.W003：你的 URL 模式 `<pattern>` 有一个 `name`，包括一个 `:`。去掉冒号，以避免模糊的命名空间引用。

- urls.E004：你的 URL 模式 `<pattern>` 无效。确保 `urlpatterns` 是一个 `path()` 和／或 `re_path()` 实例的列表。

- urls.W005：URL 命名空间 `<namespace>` 不是唯一的。你可能无法反查此命名空间中的所有 URL。

- urls.E006：`MEDIA_URL` ／`STATIC_URL` 的配置必须以斜线结束。

- urls.E007：自定义 `handlerXXX` 视图 `''path.to.view'` 没有使用正确的参数数（...）。

- urls.E008：无法导入自定义 `handlerXXX` 视图 `'path.to.view'`。

- urls.E009: 你的 URL 模式 `<pattern>` 存在无效的视图，请使用 `<view>.as_view()` 而不是 `<view>`。

- urls.W010: 你的 URL 模式 `<pattern>` 中有一个未匹配的 `<angle bracket>`。

## `contrib` 应用检查

### `admin`

后台检查项均作为 `admin` 标签的一部分执行。

以下检查项在每个通过后台站点注册的 `ModelAdmin` （或其子类）上执行。

- admin.E001： `raw_id_fields` 的值必须是个列表或元组。

- admin.E002: `raw_id_fields[n]` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E003： `raw_id_fields[n]` 的值必须是个外键或一个多对多字段。

- admin.E004： `fields` 的值必须是列表或元组。

- admin.E005： `fieldsets` 和 `fields` 都是定制的。

- admin.E006： `fields` 的值包含了重复字段。

- admin.E007： `fieldsets` 的值必须是个列表或元组。

- admin.E008： `fieldsets[n]` 的值必须是个列表或元组。

- admin.E009： `fieldsets[n]` 的值的长度必须是 2。

- admin.E010： `fieldsets[n][1]` 的值必须是个字典。

- admin.E011： `fieldsets[n][1]` 的值必须包含键 `fields`。

- admin.E012： `fieldsets[n][1]` 中有重复字段。

- admin.E013: `fields[n]/filter_horizontal[n]/filter_vertical[n]/fieldsets[n][m]` 的值不能包括 `ManyToManyField` `<field name>`，因为该字段手动指定了关系模型。

- admin.E014： `exclude` 的值必须是个列表或元组。

- admin.E015： `exclude` 的值必须包含重复字段。

- admin.E016： `form` 的值必须继承自 `BaseModelForm`。

- admin.E017： `filter_vertical` 的值必须是个列表或元组。

- admin.E018： `filter_horizontal` 的值必须是个列表或元组。

- admin.E019: `filter_vertical[n]/filter_horizontal[n]` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E020：`filter_vertical[n]/filter_horizontal[n]` 的值必须是多对多字段。

- admin.E021：`radio_fields` 的值必须是一个字典。

- admin.E022: `radio_fields` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E023 : `radio_fields` 的值指的是 `<field name>`，它不是 `ForeignKey` 的实例，也没有 `choices` 的定义。

- admin.E024：`radio_fields[<field name>]` 的值必须是 `admin.HORIZONTAL` 或 `admin.VERTICAL`。

- admin.E025：`view_on_site` 的值必须是可调用值或布尔值。

- admin.E026：`prepopulated_fields` 的值必须是一个字典。

- admin.E027: `prepopulated_fields` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E028：`prepopulated_fields` 的值指的是 `<field name>`，它不得是 `DateTimeField`、`ForeignKey`、`OneToOneField` 或 `ManyToManyField` 字段。

- admin.E029：`prepopulated_fields[<field name>]` 的值必须是一个列表或元组。

- admin.E030: `prepopulated_fields` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E031：`ordering` 的值必须是一个列表或元组。

- admin.E032：`ordering` 的值有随机排序标记 `?`，但也有其他字段。

- admin.E033: `ordering` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E034：`readonly_fields` 的值必须是一个列表或元组。

- admin.E035: `readonly_fields[n]` 的值引用了 `<field_name>`，它既不是可调用的，也不是 `<ModelAdmin class>` 的属性，也不是 `<model>` 的属性。

- admin.E036：`autocomplete_fields` 的值必须是一个列表或元组。

- admin.E037: `autocomplete_fields[n]` 的值指向了 `<field name>`，这不是 `<model>` 的字段。

- admin.E038：`autocomplete_fields[n]` 的值必须是外键或多对多字段。

- admin.E039：模型 `<model>` 的管理必须注册，才能由 `<modeladmin>.autocomplete_fields` 引用。

- admin.E040：`<modeladmin>` 必须定义 `search_fields`，因为 `<other_modeladmin>.autocomplete_fields` 引用了它。

- admin.E041: The value of `delete_confirmation_max_display` must be a non-negative integer or `None`.

#### `ModelAdmin`

对管理站点注册的任何 `ModelAdmin` 进行以下检查：

- admin.E101： `save_as` 的值必须是个布尔值。

- admin.E102： `save_on_top` 的值必须是个布尔值。

- admin.E103： `inlines` 的值必须是个列表或元组。

- admin.E104： `<InlineModelAdmin class>` 必须继承自 `InlineModelAdmin`。

- admin.E105： `<InlineModelAdmin class>` 必须有个 `model` 属性。

- admin.E106： `<InlineModelAdmin class>.model` 的值必须是个 `Model`。

- admin.E107： `list_display` 的值必须是个列表或元组。

- admin.E108: `list_display[n]` 的值引用了 `<label>`，但它不是 `<ModelAdmin class>` 的可调用对象或属性，也不是 `<model>` 的属性、方法或字段。

- admin.E109: `list_display[n]` 的值不能是多对多字段或反向外键。

- admin.E110：`list_display_links` 的值必须是一个列表、一个元组或 `None`。

- admin.E111：`list_display_links[n]` 的值指的是 `<label>`，而 `list_display` 中没有定义。

- admin.E112：`list_filter` 的值必须是一个列表或元组。

- admin.E113：`list_filter[n]` 的值必须继承自 `ListFilter`。

- admin.E114：`list_filter[n]` 的值不得继承于 `FieldListFilter`。

- admin.E115：`list_filter[n][1]` 的值必须继承自 `FieldListFilter`。

- admin.E116：`list_filter[n]` 的值指的是 `<label>`，而该值并不指一个字段。

- admin.E117：`list_select_related` 的值必须是布尔值、元组或列表。

- admin.E118：`list_per_page` 的值必须是一个整数。

- admin.E119：`list_max_show_all` 的值必须是一个整数。

- admin.E120：`list_editable` 的值必须是一个列表或元组。

- admin.E121 ： `list_editable[n]` 的值指向是 `<label>`，它不是 `<model>` 的一个字段。

- admin.E122：`list_editable[n]` 的值指的是 `<label>`，而 `list_display` 中并不包含该值。

- admin.E123：`list_editable[n]` 的值不能同时出现在 `list_editable` 和 `list_display_links` 中。

- admin.E124：`list_editable[n]` 的值是指 `list_display` （`<label>`）中的第一个字段，除非设置 `list_display_links`，否则不能使用。

- admin.E125：`list_editable[n]` 的值指的是 `<field name>`，不能通过管理编辑。

- admin.E126：`search_fields` 的值必须是一个列表或元组。

- admin.E127：`date_hierarchy` 的值指的是 `<field name>`，而该值并不指的是一个字段。

- admin.E128：`date_hierarchy` 的值必须是 `DateField` 或 `DateTimeField`。

- admin.E129：`<modeladmin>` 必须为 `<action>` 动作定义一个 `has_<foo>_permission()` 方法。

- admin.E130：`<modeladmin>` 中定义的行动的 `__name__` 属性必须是唯一的。`<name>` 这个名称不是唯一的。

#### `InlineModelAdmin`

对任何 `InlineModelAdmin` 上注册为内联的 `ModelAdmin` 进行以下检查。

- admin.E201：不能排除字段 `<field name>`，因为它是父模型 `<app_label>.<model>` 的外键。

- admin.E202：`<model>` 没有 `ForeignKey` 到 `<parent model>`./ `<model>` 有一个以上 `ForeignKey` 到 `<parent model>`。你必须指定一个 `fk_name` 属性。

- admin.E203：`extra` 的值必须是一个整数。

- admin.E204：`max_num` 的值必须是一个整数。

- admin.E205：`min_num` 的值必须是一个整数。

- admin.E206：`formset` 的值必须继承自 `BaseModelFormSet`。

#### `GenericInlineModelAdmin`

以下检查将在任何 `GenericInlineModelAdmin` 上作为内联注册的 `ModelAdmin` 上执行。

- admin.E301: `<model>` has no `GenericForeignKey`.

- admin.E302: `'ct_field'` references `<label>`, which is not a field on `<model>`.

- admin.E303: `'ct_fk_field'` references `<label>`, which is not a field on `<model>`.

- admin.E304：`<model>` 没有 `GenericForeignKey`，使用内容类型字段 `<field name>` 和对象 ID 字段 `<field name>`。

#### `AdminSite`

对默认的 `AdminSite` 进行以下检查：

- admin.E401： `django.contrib.contenttypes` 必须在 `INSTALLED_APPS` 中才能使用管理应用程序。

- admin.E402：如果使用默认的认证后端，必须在 `DjangoTemplates` （`TEMPLATES`）中启用 `django.contrib.auth.context_processors.auth`，才能使用管理程序。

- admin.E403：必须在 `TEMPLATES` 中配置一个 `django.template.backends.django.DjangoTemplates` 实例，才能使用管理程序。

- admin.E404：`django.contrib.message.context_processors.message` 必须在 `DjangoTemplates` （`TEMPLATES`）中启用，才能使用管理程序。

- admin.E405： `django.contrib.auth` 必须在 `INSTALLED_APPS` 中才能使用管理程序。

- admin.E406： `django.contrib.messages` 必须在 `INSTALLED_APPS` 中才能使用管理程序。

- admin.E408： `django.contrib.auth.middleware.AuthenticationMiddleware` 必须在 `MIDDLEWARE` 中才能使用管理应用程序。

- admin.E409： `django.contrib.messages.middleware.MessageMiddleware` 必须在 `MIDDLEWARE` 中才能使用管理应用程序。

- admin.E410： `django.contrib.session.middleware.SessionMiddleware` 必须在 `MIDDLEWARE` 中才能使用管理应用程序。

- admin.W411：必须在 `DjangoTemplates` （`TEMPLATES`）中启用 `django.template.context_processors.request` 才能使用管理员导航侧栏。

### `auth`

- auth.E001：`REQUIRED_FIELDS` 必须是一个列表或元组。

- auth.E002：`REQUIRED_FIELDS` 中不得包括名为 `USERNAME_FIELD` 的自定义用户模型字段。

- auth.E003：`<field>` 必须是唯一的，因为它被命名为 `USERNAME_FIELD`。

- auth.W004：`<field>` 被命名为 `USERNAME_FIELD`，但它不是唯一的。

- auth.E005：代号为 `<codename>` 的权限与模型 `<model>` 的内置权限发生冲突。

- auth.E006：代号为 `<codename>` 的权限与模型 `<model>` 重复。

- auth.E007：模型 `<model>` 的 `verbose_name` 必须最多 244 个字符，其内置的权限名最多只能是 255 个字符。

- auth.E008：模型 `<model>` 的权限名 `<name>` 超过 255 个字符。

- auth.C009：`<User model>.is_anonymous` 必须是一个属性或属性，而不是方法。忽略这一点是一个安全问题，因为匿名用户将被视为经过认证的用户。

- auth.C010：`<User model>.is_authenticated` 必须是一个属性或属性，而不是方法。忽略这一点是一个安全问题，因为匿名用户将被视为经过认证的用户。

- auth.E011： 模型 `<model>` 的名称最多只能是 93 个字符，其内置的权限名称最多只能是 100 个字符。

- auth.E012：代号为 `<codename>` 的模型 `<model>` 的权限超过100个字符。

- auth.E013: 为了使用 `django.contrib.auth.middleware.LoginRequiredMiddleware`，必须在 MIDDLEWARE 中先定义 `django.contrib.auth.middleware.AuthenticationMiddleware`。

### `contenttypes`

当一个模型包含 `GenericForeignKey` 或 `GenericRelation` 时，会进行以下检查：

- contenttypes.E001：`GenericForeignKey` 对象 ID 引用不存在的字段 `<field>`。

- contenttypes.E002：`GenericForeignKey` 内容类型引用不存在的字段 `<field>`。

- contenttypes.E003：`<field>` 不是一个 `ForeignKey`。

- contenttypes.E004：`<field>` 不是一个指向 `contenttypes.ContentType` 的 `ForeignKey` 。

- contenttypes.E005：模型名称最多只能是 100 个字符。

- contenttypes.E006: `<field>` cannot use the database-level `on_delete` variant.

### `postgres`

The following checks are performed on `django.contrib.postgres` model fields, indexes, and constraints:

- postgres.E001：数组的基础字段有错误：...

- postgres.E002：数组的基础字段不能是有关系的字段。

- postgres.E003：`<field>` 缺省值应该是一个可调用对象，而不是一个实例，这样它就不会被所有字段实例共享。这个检查在 Django 3.1 中被改为 *``fields.E010`` *。

- postgres.W004: 数组的基本字段存在警告：...

- postgres.E005: `'django.contrib.postgres'` must be in `INSTALLED_APPS` in order to use `<django.contrib.postgres feature>`.

### `sites`

对任何使用 `CurrentSiteManager` 的模型进行以下检查：

- sites.E001：`CurrentSiteManager` 找不到名为 `<field name>` 的字段。

- sites.E002：`CurrentSiteManager` 不能使用 `<field>`，因为它不是外键或多对多字段。

以下检查验证 `django.contrib.sites` 是否正确配置：

- sites.E101: The `SITE_ID` setting must be of type `<type>`. or The `SITE_ID` setting failed to validate: `<error>`.

### `staticfiles`

以下检查验证 `django.contrib.staticfiles` 是否正确配置：

- staticfiles.E001： `STATICFILES_DIRS` 配置不是元组或列表。

- staticfiles.E002： `STATICFILES_DIRS` 配置不应包含 `STATIC_ROOT` 配置。

- staticfiles.E003：`STATICFILES_DIRS` 设置中的前缀 `<prefix>`，不得以斜线结束。

- staticfiles.W004： `STATICFILES_DIRS` 中的目录 `<directory>` 不存在。

- staticfiles.E005: `STORAGES` 设置必须定义一个 `staticfiles` 存储。