详细阐述我的评论;
我不认为你会注意到性能上的差异，在代码、堆栈或事件请求-响应周期中有太多的地方存在瓶颈，=None与__isnull不可能成为问题。
如果发现应用程序的瓶颈是django内部的强制转换值，那么它必须是一个经过微调的应用程序和基础架构堆栈。
首先要澄清的是，django将这两行转换为完全相同的SQL查询;

• MyModel.objects.filter(relationship=None)
• MyModel.objects.filter(relationship__isnull=True)

这可以在this answer中看到
现在考虑一下这个应用程序，为了解决上述问题，所有对数据库的调用都必须尽可能快，所有调用都使用select_related和prefetch_related，只提取使用查询集的功能所需的值。
在基础设施中，你必须最小化承载应用程序的每个服务之间的延迟，然后在网站用户和你的Web服务器/CDN之间会有网络延迟。
最主要的一点是，在django的None到Null shell 之外，有太多的延迟或性能低下的可能性。
关于最佳实践等，如果你习惯用__isnull编写查询，那么你可以用它的逆来查找设置了数据的对象，这会给你的代码带来一致性，这是好代码的关键。

has_data = Model.objects.filter(field__isnull=False)
needs_data = Model.objects.filter(field__isnull=True)

为了忽略性能，使用=None而不是__isnull是一个合理的理由，因为__isnull适用于数据库中实际上没有值的null=True字段。像JSONField这样的字段可能存储一个空值，用JSON术语来说是null，但用数据库术语来说不是。有一个非常简洁的答案详细说明了here。

据我所知，这两个函数在大多数方面都很相似，因为它们都是Django的原生函数。field==None不可逆，而field__isnull=True可逆。
例如：

# You can do this ...
queryset = Model.objects.filter(field__isnull=False)

# But you can't do this ...
queryset = Model.objects.filter(field!=None)

# If you insist on the second way ...
queryset = Model.objects.filter.exclude(field=None)

如果你想反转field = None，这是一个额外的步骤，但对我来说，所有的问题是代码的一致性--如果你以前用过其中的一个，最好再次使用相同的函数，因为人们不必多次查找类似的东西。

• • 编辑**

我在Django的Queryset documentation中查找了这两个选项，我可以在侧面导航栏中看到isnull，但不能看到None，所以看起来isnull是一个更好的实践。