模型的“ full_clean”存在两个主要问题。第一个是技术性的。有几种情况根本不调用full_clean。例如，执行时将绕过它
queryset.update()。
第二个问题是，如果你具有复杂的业务逻辑（通常这就是为什么要使用full_clean的原因），那么很有可能应该在业务逻辑中进行验证，而不要深入模型进行验证。每一层都应负责其自身的一致性，而存储层（即模型）不应在意业务层。
我能想到的另一件事是，一旦你拥有在序列化程序进行验证之后出现的模型，就会调用full_clean。此时，事情开始变得混乱，因为你需要在两步验证之间创建一个对象。
如果使用
nested serializer，则可能会停留在这里，因为在保存主模型之前将无法创建嵌套模型，这将使完整的调用更为混乱-有些对象将被创建，而另一些则不会。很难确定何时以及使用他们的full_clean验证哪个对象，并且你可以确保用户在覆盖更新/清理并找出未调用full_clean时会收到很多抱怨。每个模型。这开始变得头疼不已，我们希望让事情更简单明了。
