理解Django模型字段定义中的选项(至少)有两个目的是至关重要的:定义数据库表，定义模型表单的默认格式和验证。(我说“默认”是因为可以通过提供自定义表单来覆盖这些值。)一些选项会影响数据库，一些选项会影响表单，还有一些会同时影响两者。

说到null和blank，其他答案已经说明，前者影响数据库表定义，后者影响模型验证。我认为，通过查看所有四种可能配置的用例，可以更清楚地区分它们:

null=False, blank=False: This is the default configuration and means that the value is required in all circumstances. null=True, blank=True: This means that the field is optional in all circumstances. As noted below, though, this is not the recommended way to make string-based fields optional. null=False, blank=True: This means that the form doesn't require a value but the database does. There are a number of use cases for this: The most common use is for optional string-based fields. As noted in the documentation, the Django idiom is to use the empty string to indicate a missing value. If NULL was also allowed you would end up with two different ways to indicate a missing value. (If the field is also unique, though, you'll have to use null=True to prevent multiple empty strings from failing the uniqueness check.) Another common situation is that you want to calculate one field automatically based on the value of another (in your save() method, say). You don't want the user to provide the value in a form (hence blank=True), but you do want the database to enforce that a value is always provided (null=False). Another use is when you want to indicate that a ManyToManyField is optional. Because this field is implemented as a separate table rather than a database column, null is meaningless. The value of blank will still affect forms, though, controlling whether or not validation will succeed when there are no relations. null=True, blank=False: This means that the form requires a value but the database doesn't. This may be the most infrequently used configuration, but there are some use cases for it: It's perfectly reasonable to require your users to always include a value even if it's not actually required by your business logic. After all, forms are only one way of adding and editing data. You may have code that is generating data that doesn't need the same stringent validation you want to require of a human editor. Another use case that I've seen is when you have a ForeignKey for which you don't wish to allow cascade deletion. That is, in normal use the relation should always be there (blank=False), but if the thing it points to happens to be deleted, you don't want this object to be deleted too. In that case you can use null=True and on_delete=models.SET_NULL to implement a simple kind of soft deletion.

null = True

意味着没有数据库对要填充的字段的约束，因此您可以有一个具有此选项的填充的空值对象。

blank = True

意味着在django表单中没有验证约束。所以当你为这个模型填写一个modelForm时，你可以不填这个选项。

你可能有你的答案，但直到今天，很难判断是否把null=True或空白=True或两者都放在一个字段。我个人认为为开发者提供这么多选择是非常无用和令人困惑的。让它按自己的意愿处理空值或空格。

下面是来自Two Scoops of Django的表格:

简单的回答是:Null是数据库表，Blank是Django表单。

下表显示了主要的区别:

+--------------------------------------------------------------------+
| Purpose                  | null=True        | blank = True         |
|--------------------------|------------------|----------------------|
| Field can be empty in DB | Do this          | Unaffected           |
|--------------------------|------------------|----------------------|
| ModelForm(required field)| Unaffected       | field not required   |
|--------------------------|------------------|----------------------|
| Form Validation          | Unaffected       | field not required   |
|--------------------------|------------------|----------------------|
| on_delete=SET_NULL       | Need this        | Unaffected           |
+--------------------------------------------------------------------+

当你说null=False时，这意味着数据必须传递到数据库保存。当你说空白=False时，这意味着数据必须从前端输入，反之亦然