django多进程部署时全局变量“消失”是因为gunicorn每个worker是独立进程，内存不共享；view1中修改的全局字典仅存在于当前worker内存中，后续请求若路由到其他worker则看到初始空字典。正确做法是改用django缓存系统（如redis或memcached），通过cache.set()和cache.get()实现跨进程一致访问。

为什么Django多进程部署时全局变量“消失”了

因为Gunicorn每个worker都是独立进程，内存不共享。你在view1里往my_global_dict里塞的数据，只存在于那个worker的内存里；下一次请求被分到另一个worker，看到的就是空的my_global_dict——不是bug，是进程隔离的正常行为。

Django里该用什么替代全局字典

别碰进程内全局变量，改用Django原生缓存层，它天然支持跨进程访问：

• CACHES配置指向Redis或Memcached（不推荐locmem，它仍是进程级）
• 所有worker都通过同一套缓存后端读写，数据自动一致
• 用cache.set("key0", obj)和cache.get("key0")替代my_global_dict["key0"] = obj
• 注意序列化限制：缓存只存可序列化对象，MyClass实例需实现__getstate__或转成dict/json

直接用multiprocessing.Manager()行不行

不行，也不该在Django Web服务中这么干：

Python 3.14.2

Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。

下载

• multiprocessing.Manager().dict()依赖一个单独的管理进程，它无法被Gunicorn worker自动继承或发现
• 每个worker启动时都会新建自己的Manager，结果还是各管各的
• 即使硬编码共享，也会因Gunicorn的pre-fork模型导致Manager在fork前未初始化，引发RuntimeError
• 这不是Web应用该承担的复杂度，缓存系统才是正解

开发环境能跑通，上线就出问题？检查这几点

这是最典型的误判来源：

• 确认你用的是python manage.py runserver（单进程） vs gunicorn myproject.wsgi:application --workers 3（多进程）
• 用os.getpid()打印日志，验证不同请求是否落在不同PID上
• 别在settings.py或模块顶层直接初始化全局字典，那只是每个worker各自执行一遍
• 临时调试时可在视图里加print(f"PID: {os.getpid()}, dict: {my_global_dict}")，立刻暴露隔离现象

真正要共享的状态，从来就不该靠内存变量承载；缓存、数据库、消息队列——这些才是生产环境里“可见”的地方。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！