Flask中存储变量的最优方案：用session还是跨请求全局变量？

关于session存储的合理性 #

• Flask的g变量是请求上下文绑定的临时变量，生命周期仅覆盖单个请求处理周期，请求结束后就会被销毁。你之前部署在IIS上出现旧值残留，核心原因是IIS配套的WSGI容器默认采用多进程/多线程模式处理请求，若你没有为每个请求重新初始化g的属性，上一个请求遗留的g属性值就会被下一个同进程/线程处理的请求读取，这是g的设计特性决定的，它本身就不支持存储会话级或跨请求的数据。
• 你当前的场景用session存储是完全合理的。默认Flask的session基于签名cookie实现，只要你存储的10+变量总大小不超过cookie单条4KB的上限（普通字符串、数字类型的变量完全不会触及该阈值），就可以稳定运行。如果后续数据量超过cookie限制，也可以引入flask-session扩展将session存储在本地文件系统、内存缓存等位置，适配你不能使用数据库的要求。

关于跨请求全局变量的可行性 #

• 生产环境绝对不推荐用全局变量存储会话级数据，不存在比session更优的说法。生产环境为了支撑并发请求，都会启用多worker、多线程/协程的运行模式，全局变量仅在单个进程内共享，不同进程的全局变量完全隔离，同时多线程修改全局变量还会存在竞态条件，不仅会出现旧值残留的问题，还会导致不同会话的数据互相串用，完全不符合业务数据隔离的要求。
• 你遇到的生产环境全局变量效果不符合预期的问题，就是运行模式差异导致的：本地开发环境默认是单worker单线程模式，全局变量修改后所有请求都能读到，看起来运行正常，但生产环境的多进程/多线程模式下，不同请求可能被不同进程/线程处理，A请求修改的全局变量值，B请求完全可能读不到，甚至被其他请求的修改覆盖，自然表现不符合预期。

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