生产中神秘的Django API行为

长期阅读，但刚加入社区。我有一个神秘的问题，我想寻求帮助。由于这是目前正在生产中运行的代码的一部分，我需要编辑部分信息，并在需要时提供信息。如果需要，我还将制作一个新的示例代码，以确保我们都可以进行测试，并指导我解决问题的正确方法

目前，有一个web应用程序（django/wagtail/coderedcms）后端需要转换为移动应用程序。为了允许移动应用程序与后端服务器通信，我使用Django rest框架实现了一个API端点。为了对用户进行身份验证，我已经使用Django rest simplejwt实现了一个简单的身份验证端点。这部分工作正常。应用程序的要求之一是用户必须能够通过移动应用程序查看/更新其个人资料

在my localhost的dev server中工作时，行为与预期一致，每个用户都可以使用应用程序登录，后端将发送回令牌，随后将使用tokan访问应用程序的各个部分

当相同的代码库在生产中实施时（目前处于UAT阶段），发现一种行为，如果多个用户同时登录，服务器将只返回请求配置文件的第一个用户的配置文件。
意思：
用户A已登录…
用户B已登录…
用户B请求查看其个人资料（显示个人资料B）

---

用户请求查看其配置文件（显示了配置文件B）我在猜测，因为没有太多关于可能导致错误的信息。如果在生产环境中未运行单独的缓存系统（如Redis），则此错误可能是由客户端引起的。你有没有用Postman这样的工具尝试过同样的场景？

听起来像是缓存问题。谢谢，我想是的。请参阅我对Postman原始帖子的编辑。我也不使用单独的缓存系统。你确定你在本地运行了Nginx吗？WSGI在发送到localhost的请求中显示为web服务器。如果Nginx中有任何缓存设置，则可能与此相关。如果您不使用Nginx逐个管理项目中的位置，我建议您在Django中而不是Nginx中设置公共和私有缓存设置。

allow →GET, POST, OPTIONS
cache-control →max-age=300
connection →keep-alive
content-encoding →gzip
content-type →application/json
date →Wed, 25 Nov 2020 20:59:03 GMT
expires →Wed, 25 Nov 2020 21:03:30 GMT
server →nginx/1.17.4
strict-transport-security →max-age=31536000
transfer-encoding →chunked
vary →Accept, Origin, Cookie
x-cdn →Incapsula
x-content-type-options →nosniff
x-frame-options →ALLOWALL
x-iinfo →4-22327133-22328885 NNYN CT(2 2 0) RT(1606337880159 62932) q(0 0 0 -1) r(1 1) U16
x-wagtail-cache →hit

allow →POST, GET, OPTIONS
content-length →204
content-type →application/json
date →Wed, 25 Nov 2020 20:57:45 GMT
server →WSGIServer/0.2 CPython/3.8.5
vary →Accept, Origin
x-content-type-options →nosniff
x-frame-options →DENY