Django乐观锁与版本号防并发冲突实现

Django默认的save()方法不提供并发控制，导致多个用户同时编辑同一条记录时可能出现“后提交者静默覆盖前修改”的数据丢失问题；本文深入剖析了如何通过乐观锁（添加version字段并结合条件更新与F()表达式实现原子校验）来安全、高效地防止并发冲突，同时指出悲观锁select_for_update()在Web场景中的局限性与风险，并强调前后端协同（如隐藏版本号字段、提交时校验、友好错误提示）的必要性，最终提醒开发者：解决并发问题的关键不在于技术堆砌，而在于根据业务实际权衡一致性需求——有些场景用Redis原子操作反而比数据库锁更简洁可靠。

并发修改时数据被悄悄覆盖，Django 默认不防

Django 的 save() 方法默认是“写后即覆”，没有内置的并发冲突检测。两个请求同时读取同一条记录、各自修改后调用 save()，后提交者会无感知地覆盖前者的修改——这不是 bug，是设计使然。想防止这种覆盖，得自己加控制，最常用的是乐观锁配合版本号字段。

给模型加 version 字段并重写 save()

核心思路：每次更新都检查当前数据库里的 version 是否等于你读取时的值；不一致就说明已被他人改过，抛异常或拒绝保存。

• 在模型中添加 version 字段：version = models.IntegerField(default=0)
• 重写 save() 方法，使用 update() 带条件更新，并检查影响行数
• 必须用 F() 表达式避免竞态：不能先 obj.version += 1 再 save()，否则两次读+写之间仍有窗口

from django.db import models
from django.db.models import F
class Article(models.Model):
title = models.CharField(max_length=100)
content = models.TextField()
version = models.IntegerField(default=0)
def save(self, *args, **kwargs):
    if self.pk:
        # 已存在：尝试原子更新，只在 version 匹配时才改
        updated = Article.objects.filter(
            pk=self.pk,
            version=self.version
        ).update(
            title=self.title,
            content=self.content,
            version=F('version') + 1
        )
        if not updated:
            raise ValueError('Concurrent update detected: version mismatch')
    else:
        # 新建：正常插入，version 从 0 开始
        self.version = 0
        super().save(*args, **kwargs)

select_for_update() 是悲观锁，别在 Web 请求里滥用

有人看到“防并发”第一反应是 select_for_update()，但它在 Django 中依赖数据库行锁，会阻塞其他事务，且 HTTP 请求生命周期长、连接池有限，容易引发锁等待甚至超时。它适合短时强一致性场景（如库存扣减），不适合通用编辑表单。

• select_for_update() 必须在 transaction.atomic() 块内使用，否则无效
• PostgreSQL 支持 select_for_update(nowait=True) 避免无限等待，但 MySQL 不支持 nowait
• 如果用户打开编辑页后挂机 10 分钟再提交，锁可能早已释放，但你的业务逻辑未必能处理这种状态漂移

前端也得配合：把版本号传回来再校验

光靠后端拦不住“页面老数据提交”。用户 A 打开编辑页（读到 version=5），用户 B 提交成功（version 变成 6），此时 A 还在填表。如果不把初始 version 一起提交，后端根本不知道该拿哪个值去比。

• 模板里藏一个隐藏字段：
• 视图中从 request.POST 拿出 version，赋给模型实例再调用 save()
• 捕获 ValueError 异常，返回友好提示：“内容已被他人更新，请刷新后重试”

真正难的不是加字段或写几行代码，而是想清楚：这个业务是否真的需要强一致性？能不能接受最终一致？比如评论点赞，用 Redis 原子计数器往往比数据库行级锁更合适。

本篇关于《Django乐观锁与版本号防并发冲突实现》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！