Windows上Pool传非全局函数报错，因spawn机制下子进程无法导入嵌套函数、lambda等非顶层定义的函数，导致PicklingError或AttributeError；仅模块顶层可导入且可pickle的函数才安全。
为什么 Windows 上 Pool 传非全局函数会报错
Windows 使用 spawn 方式启动子进程，不像 Linux 的 fork 能直接复制父进程内存状态。子进程启动时会重新导入主模块，此时若 map 或 apply_async 引用的是局部定义的函数（比如嵌套函数、lambda、类方法、或函数内定义的函数），子进程找不到该函数对象，就会抛出 PicklingError: Can't pickle 或 AttributeError: module '__main__' has no attribute 'xxx'。
哪些函数能被 Pool 安全传递
只有「可被 pickle 序列化且模块顶层可导入」的函数才安全。具体包括：
-
def在模块最外层定义的普通函数（非嵌套） - 内置函数（如
len、str.upper） - 类的静态方法（
@staticmethod）和类方法（@classmethod），但必须定义在模块顶层类中 - 第三方包里的函数（如
math.sqrt）
以下全部不合法：lambda x: x*2、def inner(): ...（在另一个函数里）、self.method、obj.method。
绕过限制的三种实操方案
方案不是“修复”，而是适配 Windows 的 spawn 机制：
立即学习“Python免费学习笔记（深入）”；
-
把函数提级到模块顶层：哪怕只是临时封装，也比嵌套更可靠。例如把循环里动态生成的逻辑抽成独立
def worker(args)，再用functools.partial绑定部分参数 -
用
concurrent.futures.ProcessPoolExecutor替代multiprocessing.Pool：它对 Windows 友好性更好，且支持submit直接传带闭包的函数（底层做了额外序列化处理，但仍有边界——不能含不可序列化的对象） -
改用
pathos.multiprocessing（需pip install pathos）：它用dill替代pickle，能序列化 lambda、嵌套函数甚至部分实例方法，但性能略低、调试信息更难读，且不兼容所有 C 扩展对象
一个典型错误与修正对比
错误写法（Windows 下必崩）：
from multiprocessing import Pooldef main(): def square(x): # ❌ 嵌套函数，子进程无法导入 return x ** 2 with Pool() as p: print(p.map(square, [1,2,3])) # PicklingError
if name == 'main': main()
正确写法（任选其一）：
- 提级函数：
def square(x): return x**2放在if __name__ == '__main__':外面 - 用
ProcessPoolExecutor：from concurrent.futures import ProcessPoolExecutor，然后executor.submit(square, 5)（square仍需顶层定义） - 用
pathos：from pathos.multiprocessing import ProcessPool as Pool，原代码几乎不用改
真正容易被忽略的点是：即使用了 if __name__ == '__main__':，也不能拯救嵌套函数——spawn 机制下，子进程只执行模块顶层语句，不会执行 main() 函数体内的任何定义。
