Django偶发丢失session数据，配置强制保存仍无效如何排查？

你已经配置的SESSION_SAVE_EVERY_REQUEST、手动设置modified=True、手动调用save()这些操作都是正确的，已经排除了session修改未被检测到的问题，不用在这方面继续排查。以下是按优先级排序的问题原因和对应解决方案：

1. 最高概率：并发请求的session写入竞争 #

这是Django session偶发丢失的最典型场景，且你测试文件存储session时也复现了问题，刚好排除了缓存、数据库层的独有问题，进一步印证了这个可能性。
当同一个用户的多个请求（比如页面多个异步接口同时发起、用户快速点击触发多次请求）在短时间内同时到达时，会出现如下时序：

• 请求A读取到当前版本的session数据
• 请求B在请求A完成写入前，也读取到了同一份未修改的session数据
• 请求A添加了question_list字段后写入session存储
• 请求B基于自己之前读取的旧版本session（没有question_list字段）完成修改后写入，直接覆盖了请求A的改动
  你看到的「视图内日志打印有值，但最终存储无值」完全符合这个特征：请求A的改动被后完成的请求B直接覆盖了。
  你使用cached_db模式时，缓存和数据库的双层写入逻辑会进一步放大这个竞争问题。

对应解决方法 #

给请求添加唯一请求ID日志，同时打印session的session_key和修改时间，观察每次出现session丢失的时间点，是否有同一个session_key的其他请求同时在处理。
如果确认是并发问题：

• 非核心数据可以接受偶发丢失的话，尽量避免在多个异步接口中同时修改同一份session字段
• 核心数据不要存储在session中，直接写入关联的用户表字段
• 可以自定义Django session后端，写入前对session数据库行加select_for_update排他锁，避免覆盖写入

2. 次高概率：事务回滚导致session写入失效 #

Django的数据库session（包括cached_db模式的数据库写入环节）默认会加入当前请求的数据库事务中：

• 如果你开启了全局ATOMIC_REQUESTS配置，或者视图加了@transaction.atomic装饰器，整个请求的所有数据库操作会被包裹在同一个事务里
• 即使你的视图代码本身正常返回了响应，只要后续环节（比如模版渲染、响应处理中间件、请求结束触发的信号回调）抛出未捕获的异常，整个事务会被回滚，session的写入操作也会一并回滚，最终数据库中不会有对应记录
  如果你的业务逻辑中包含大量数据库操作，这个问题的出现概率会更高。

对应解决方法 #

开启Django的数据库SQL日志，观察session写入的UPDATE/INSERT语句是否正常执行：

• 如果SQL语句已经执行但库中无数据，必然是事务回滚导致，检查请求全链路是否有未捕获的异常，或者是否有逻辑主动触发了事务回滚
• 可以将session的数据库操作配置为使用独立的非事务数据库连接，避免和业务逻辑的事务绑定

3. 缓存配置相关问题 #

• 你最初使用的LocMemCache是进程级别的缓存，多进程部署（uWSGI/Gunicorn开启多worker）时，不同进程的缓存数据完全隔离，请求打到不同worker时会读取到不一致的session缓存，最终写入时出现覆盖
• 如果你换用memcached后仍然有问题，要检查memcached的内存配置：如果缓存容量不足，session数据可能会被LRU策略主动淘汰，导致cached_db模式读取缓存失效，退化成读数据库时拿到旧版本数据，写入时覆盖新改动

对应解决方法 #

多进程部署场景下禁止使用LocMemCache作为全局缓存，确认memcached/redis的内存配置足够存放所有session数据，避免主动淘汰。

其他低概率原因 #

如果排查完上面的问题都没有发现异常，可以检查question_list的大小：如果这个列表的数据量极大，序列化后的长度超过了存储后端的限制（比如memcached单key默认1M上限、数据库session字段默认是TEXT类型的长度限制），也会导致写入失败。不过你测试文件存储也复现了问题，这个情况的概率较低。

内容的提问来源于stack exchange，提问作者OritK