类变量在多进程 fork 后的行为与修改陷阱

fork后类变量不共享。子进程获得父进程内存副本，类变量初始值相同但物理隔离，修改互不影响；可变对象的就地修改看似生效实为COW机制下的短暂共享，后续写操作即触发内存分离。

fork 后类变量是否共享？

不共享。fork 创建的是子进程的完整内存副本，包括所有已加载的 python 模块、类对象及其类变量。子进程修改类变量（如 MyClass.counter）不会影响父进程，反之亦然——这是“写时复制”（copy-on-Write）机制下实际发生的物理隔离，不是逻辑上的“引用共享”。

常见错误现象：在父进程中初始化 MyClass.config = {'debug': True}，然后启动多个子进程并各自修改该字典，结果发现父进程看不到任何变更，且各子进程之间也互不可见。这不是 bug，是预期行为。

为什么修改可变类变量会“看似生效”？

因为类变量本身是对象引用，而可变对象（如 list、dict）的就地修改（.append()、['key'] = val）不改变引用地址，只改变其所指对象的内容。子进程 fork 时复制的是该引用，指向同一块堆内存——但注意：这仅在 fork 瞬间成立；一旦任一进程对该可变对象执行写操作，内核会触发 COW，为该页分配新物理内存，后续修改即完全隔离。

实操建议：

• 不要依赖 fork 后对类变量中可变对象的“跨进程可见性”，它不可靠且难以调试
• 若需父子/兄弟进程通信，请用 multiprocessing.Manager、multiprocessing.Queue 或文件/redis 等显式 IPC 机制
• 把类变量当作只读配置项使用更安全；如需运行时状态，应明确设计为进程局部实例属性（self.state）或外部存储

类变量 + multiprocessing.Process 的典型误用

很多人写类似这样的代码：

class Worker:     log_buffer = [] 
def run(self):     self.log_buffer.append("started")  # ← 错！     time.sleep(1)     print(self.log_buffer)  # ← 总是只看到 ["started"]，且每次都是独立副本

问题在于：log_buffer 是类变量，但每个 Process 实例运行在独立地址空间，append 修改的是自己副本里的 list 对象。即使你用 @classmethod 调用，也无法突破进程边界。
正确做法：

把日志收集逻辑移到主进程，子进程通过 Queue.put() 发送日志条目
若必须用类变量做缓存，确保它只在单进程内生命周期内使用（例如 Web 请求处理中的线程局部缓存），而非跨 fork 场景
用 if __name__ == '__main__': 保护入口，避免 windows 下 spawn 模式重复导入导致类变量被多次初始化

fork vs spawn 模式下的类变量差异
linux 默认用 fork，macOS 和 windows 默认用 spawn。二者对类变量的影响完全不同：

 fork：子进程继承父进程整个解释器状态，包括所有已导入模块的类变量值（初始一致，之后隔离）
 spawn：子进程重新导入模块、重建类对象，类变量按定义时的表达式重新求值（如 counter = 0 重置，但 cache = get_expensive_dict() 会重复执行）

这意味着：依赖类变量做计数器或单例缓存的代码，在 spawn 下可能意外重置，而在 fork 下可能残留旧值。跨平台项目务必避免在类变量中存放需要一致性状态的数据。
最容易被忽略的一点：你写的测试可能只在 Linux 上跑过，没碰过 Windows 的 spawn 行为，上线后才发现类变量“突然不工作了”。