这个问题我太熟了——哪怕你没显式调用pickle，spawn启动模式的底层机制也会强制用到它，这就是错误的核心原因。

先搞懂fork和spawn的本质区别 #

• fork模式：直接复制父进程的整个内存空间，子进程和父进程共享同一套内存数据，不需要做任何序列化操作，所以你之前用fork没问题。
• spawn模式：会启动一个全新的Python解释器进程，然后必须把要执行的函数、函数依赖的所有变量/对象都通过pickle序列化后传递给子进程，子进程反序列化后再执行函数。这一步是自动发生的，你看不到但它确实在运行。

为什么会出现"Can't pickle <class 'module'>"错误？ #

这个错误说明你的目标函数（或者它依赖的闭包、全局变量）里直接或间接引用了模块对象，而绝大多数模块是不能被pickle序列化的（内置模块偶尔可以，但自定义模块或带特殊状态的模块基本不行）。举几个常见场景：

• 你的函数里捕获了一个模块级别的变量，而这个变量本身就是模块对象（比如import my_mod后，函数里直接用了my_mod而不是my_mod.some_func）；
• 你把模块对象作为参数传递给了子进程的目标函数；
• 函数定义所在的模块没有正确用if __name__ == '__main__':防护，导致子进程重新导入模块时触发了额外的逻辑，间接引入了不可序列化的模块对象。

具体的排查和解决办法 #

• 避免传递模块对象，在子进程内重新导入：如果函数需要用到模块里的功能，不要直接传递模块本身，而是把import语句移到目标函数内部，让子进程自己导入模块；
• 严格用if __name__ == '__main__':防护主逻辑：spawn模式下子进程会重新执行主模块代码，没有这个防护的话，子进程会重复创建进程，还可能导致模块导入异常，间接引发pickle错误；
• 排查闭包和全局变量：如果你的目标函数是嵌套函数，检查它有没有捕获父作用域里的模块对象或者其他不可序列化的对象；
• 本地化依赖属性：如果必须用父进程的模块资源，不要直接引用模块，而是单独提取需要的函数或变量（比如func = my_mod.do_something，再让函数调用func()）。

举个错误示例（会触发报错）：

import custom_module

def background_task(mod):
    mod.run()

if __name__ == '__main__':
    import multiprocessing
    multiprocessing.set_start_method('spawn')
    p = multiprocessing.Process(target=background_task, args=(custom_module,))
    p.start()

修改后（解决问题）：

def background_task():
    import custom_module
    custom_module.run()

if __name__ == '__main__':
    import multiprocessing
    multiprocessing.set_start_method('spawn')
    p = multiprocessing.Process(target=background_task)
    p.start()

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