生产环境下Django自定义类实例的两种处理方案选型咨询

核心差异：状态隔离性 #

两种方案的本质区别在于实例是否被多个请求共享，直接决定了各自的适用场景：

方案1：模块级单实例 #

• 特点：实例在模块加载时创建，驻留于进程内存中，同一进程内的所有请求共享该实例。
• 适用场景：仅当你的Calc类是无状态的——即run方法不依赖或修改实例的任何属性，每次计算都是独立的纯逻辑操作。这种情况下，复用单实例能避免重复初始化的开销，性能更优。
• 风险：如果Calc类存在状态（比如实例内有缓存变量、计数器，或run方法会修改实例属性），多个请求会共享这些状态，导致数据错乱（比如前一个请求的计算残留影响后一个请求）。生产环境多进程模式下，每个进程会有自己的实例，但同一进程内的请求仍会受影响。

方案2：请求内创建实例 #

• 特点：每个请求触发时创建新实例，请求结束后实例被回收，完全隔离请求间的状态。
• 适用场景：所有存在状态的自定义类，或不确定未来是否会添加状态的场景。即使是无状态类，这种方式的性能开销在绝大多数业务场景下可以忽略不计。
• 优势：彻底避免跨请求的状态污染问题，代码更健壮，后续维护时无需担心因添加状态而引发潜在bug。

生产环境表现对比 #

生产服务器（如Gunicorn、uWSGI）多采用多进程模式：

• 方案1：每个进程会独立加载模块，因此每个进程有自己的calc_instance，实例是进程级共享，而非全局跨进程共享。无状态场景下，比方案2少了实例化开销，性能略优。
• 方案2：每个请求都创建新实例，进程内各请求的实例完全独立，无论是否有状态都能保证数据安全，性能开销可忽略。

推荐结论 #

1. 若Calc类明确为无状态，且后续不会添加状态逻辑：优先选方案1，兼顾性能与简洁。
2. 若Calc类有状态，或无法确定未来的状态变化：必须选方案2，确保业务逻辑的稳定性。

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