系统检查框架是一组验证Django项目的静态检查。 它检测到常见的问题，并提供了如何解决这些问题的提示。 该框架是可扩展的，所以你可以轻松地添加自己的检查。
\n通过 check 命令来显示的触发检查操作。检查会在大多数命令之前被隐式触发，包括 runserver 和 migrate 。出于性能原因，检查不会作为部署中使用的 WSGI 堆栈的一部分来运行。如果你需要在部署系统上运行系统检查，可以使用 check 来触发他们。
严重的错误将阻止 Django 命令（比如 runserver）运行。小问题将会在控制台上报告出来。如果你已经检查了警告的原因并愿意忽略它，你可以在 settings.py 文件里的 SILENCED_SYSTEM_CHECKS 设置隐藏指定的警告。
Django 引发的所有检查的完整列表在 System check reference 中可查。
\n框架是可伸缩的，并且允许你编写函数来执行其他你需要的其他检查。举例：
\nfrom django.core.checks import Error, register\n\n\n@register()\ndef example_check(app_configs, **kwargs):\n errors = []\n # ... your check logic here\n if check_failed:\n errors.append(\n Error(\n "an error",\n hint="A hint.",\n obj=checked_object,\n id="myapp.E001",\n )\n )\n return errors\ncheck 函数必须接受一个 app_configs 参数；这个参数是应该被检查的应用程序的列表。如果为 None，则必须在项目中的 所有 已安装的应用程序上运行检查。
检查将接收一个 databases 关键字参数。这是一个数据库别名的列表，其连接可能用于检查数据库级别的配置。如果 databases 为 None，则检查必须不使用任何数据库连接。
**kwargs 参数是为了将来扩展而必需的。
函数必须返回消息列表。如果检查结果没有发现问题，检查函数必须返回空列表。
\n警告和错误由必须是 CheckMessage 的检查方法引发。CheckMessage 的实例概括了错误或警告。它也提供适合消息的上下文和消息，和用来过滤目的的唯一标示。
这个概念与来自 message framework or the logging framework 的消息非常相似。消息标有 level ，标示消息的严重性。
也可以有快捷方式来简单创建公共级别的消息。当使用这些类你可以忽略 level 参数，因为它已经通过类名隐含。
最后，你的检查函数必须已经在系统检查注册表明确注册。检查应该在加载应用程序时加载文件中注册；比如，在 AppConfig.ready() 方法中。
为了标记检查，你可以根据需要来传递很多标签给 register。标记检查很有用，因为它允许你仅运行一个特定的检查组。比如，为了注册一个兼容性检查，你可以进行以下调用：
from django.core.checks import register, Tags\n\n\n@register(Tags.compatibility)\ndef my_check(app_configs, **kwargs):\n # ... perform compatibility checks and collect errors\n return errors\n你可以注册仅与生产配置文件相关的"部署检查" ：
\n@register(Tags.security, deploy=True)\ndef my_check(app_configs, **kwargs): ...\n这些检查只在使用 check --deploy 选项时运行。
你也可以把 register 当做函数而不是装饰器，通过传递一个可调用对象（通常是函数）作为第一参数传递给 register。
下面的代码和上面的代码等同：
\ndef my_check(app_configs, **kwargs): ...\n\n\nregister(my_check, Tags.security, deploy=True)\n在某些情况下，你不需要注册检查函数——你可以使用现有的注册。
\nFields, constraints, models, model managers, template engines, task backends,\nand database backends all implement a check() method that is already\nregistered with the check framework. If you want to add extra checks, you can\nextend the implementation on the base class, perform any extra checks you need,\nand append any messages to those generated by the base class. It's recommended\nthat you delegate each check to separate methods.
考虑一个例子，你正在实现一个自定义字段 RangedIntegerField。这个字段添加 min 和 max 参数给 IntegerField 的构造器。你可能想添加一个检查来确保用户提供小于或等于最大值的最小值。下面的代码片段显示如何实现这个检查：
from django.core import checks\nfrom django.db import models\n\n\nclass RangedIntegerField(models.IntegerField):\n def __init__(self, min=None, max=None, **kwargs):\n super().__init__(**kwargs)\n self.min = min\n self.max = max\n\n def check(self, **kwargs):\n # Call the superclass\n errors = super().check(**kwargs)\n\n # Do some custom checks and add messages to `errors`:\n errors.extend(self._check_min_max_values(**kwargs))\n\n # Return all errors and warnings\n return errors\n\n def _check_min_max_values(self, **kwargs):\n if self.min is not None and self.max is not None and self.min > self.max:\n return [\n checks.Error(\n "min greater than max.",\n hint="Decrease min or increase max.",\n obj=self,\n id="myapp.E001",\n )\n ]\n # When no error, return an empty list\n return []\n如果你想对模型管理器添加检查，你应该对 Manager 的子类采用相同方法。
如果你想对模型类添加检查，这个方法几乎相同，唯一的区别是这个检查是一个类方法，而不是实例方法。
\nclass MyModel(models.Model):\n @classmethod\n def check(cls, **kwargs):\n errors = super().check(**kwargs)\n # ... your own checks ...\n return errors\n消息具有可比性。允许你轻松编写测试：
\nfrom django.core.checks import Error\n\nerrors = checked_object.check()\nexpected_errors = [\n Error(\n "an error",\n hint="A hint.",\n obj=checked_object,\n id="myapp.E001",\n )\n]\nself.assertEqual(errors, expected_errors)\n由于在应用程序加载时需要注册某些检查，因此测试它们在系统检查框架内的集成可以是有用的。这可以通过使用 call_command() 函数来实现。
例如，这个测试演示了:setting:SITE_ID 设置必须是一个整数，这是来自站点框架的内置 检查:
\nfrom django.core.management import call_command\nfrom django.core.management.base import SystemCheckError\nfrom django.test import SimpleTestCase, modify_settings, override_settings\n\n\nclass SystemCheckIntegrationTest(SimpleTestCase):\n @override_settings(SITE_ID="non_integer")\n @modify_settings(INSTALLED_APPS={"prepend": "django.contrib.sites"})\n def test_non_integer_site_id(self):\n message = "(sites.E101) The SITE_ID setting must be an integer."\n with self.assertRaisesMessage(SystemCheckError, message):\n call_command("check")\n考虑以下检查，如果自定义设置 ENABLE_ANALYTICS 未设置为 True，则在部署时发出警告：
from django.conf import settings\nfrom django.core.checks import Warning, register\n\n\n@register("myapp", deploy=True)\ndef check_enable_analytics_is_true_on_deploy(app_configs, **kwargs):\n errors = []\n if getattr(settings, "ENABLE_ANALYTICS", None) is not True:\n errors.append(\n Warning(\n "The ENABLE_ANALYTICS setting should be set to True in deployment.",\n id="myapp.W001",\n )\n )\n return errors\n鉴于这个检查不会引发 SystemCheckError，可以通过以下方式断言 stderr 输出中存在警告消息：
from io import StringIO\n\nfrom django.core.management import call_command\nfrom django.test import SimpleTestCase, override_settings\n\n\nclass EnableAnalyticsDeploymentCheckTest(SimpleTestCase):\n @override_settings(ENABLE_ANALYTICS=None)\n def test_when_set_to_none(self):\n stderr = StringIO()\n call_command("check", "-t", "myapp", "--deploy", stderr=stderr)\n message = (\n "(myapp.W001) The ENABLE_ANALYTICS setting should be set "\n "to True in deployment."\n )\n self.assertIn(message, stderr.getvalue())\n