简短的答案，这确实不是所提出的Django问题。
并发控制通常是一个技术问题，但在许多方面却是功能需求问题。您希望/需要您的应用程序如何工作？在不知道这一点之前，很难给出任何特定于Django的建议。
但是，我感觉很漫无边际，所以这里…
当面对并发控制的需求时，我倾向于问自己两个问题：
- 两个用户需要同时修改同一记录的可能性有多大？
- 如果丢失了对记录的修改，对用户有什么影响？
如果冲突的可能性相对较高，或者丢失修改的影响严重，那么您可能正在寻找某种形式的悲观锁定。在悲观方案中，每个用户必须在打开记录进行修改之前获得逻辑锁。
悲观锁定会带来很多复杂性。您必须同步对锁的访问，考虑容错性，锁到期，超级用户可以覆盖锁，用户可以看到谁拥有该锁，等等。
在Django中，可以使用单独的Lock模型或锁定记录上的某种“ lock
user”外键来实现。使用锁表在获取锁时，用户，便笺等方面的存储方面具有更大的灵活性。如果您需要可用于锁定任何类型的记录的通用锁表，请查看django.contrib.contenttypes框架，但是很快它可以演变为抽象的宇航员综合症。
如果冲突不太可能或丢失的修改被重新创建，那么您可以在功能上摆脱乐观并发技术的束缚。该技术简单易行。本质上，您只需跟踪版本号或修改时间戳，并拒绝您发现的任何修改。
从功能设计的角度来看，您只需要考虑如何将这些并发的修改错误呈现给用户。
对于Django而言，可以通过覆盖模型类上的save方法来实现乐观并发控制。
def save(self, *args, **kwargs): if self.version != self.read_current_version(): raise ConcurrentModificationError('Ooops!!!!') super(MyModel, self).save(*args, **kwargs)而且，当然，要使这两种并发机制都健壮起来，就必须考虑事务控制。如果您不能保证交易的ACID属性，则这两种模型都无法完全使用。
