multiprocessing.Pool 直接 map pandas.DataFrame 报错因 DataFrame 默认无法被 pickle 完整序列化，尤其含自定义方法、扩展类型或未关闭文件句柄时；实操应传 numpy.ndarray 或纯 Python 数据结构，避免传整个 DataFrame。
为什么 multiprocessing.Pool 直接 map pandas.DataFrame 会报错
因为 DataFrame 默认不能被 pickle 完整序列化（尤其含自定义方法、某些扩展类型或未关闭的文件句柄时），而 multiprocessing 子进程必须靠 pickle 传递数据。常见报错是 AttributeError: Can't pickle local object 或 TypeError: cannot serialize '_io.TextIOWrapper'。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把数据切片逻辑放在主进程，只传
numpy.ndarray或纯 Python 字典/列表给子进程，避免传整个DataFrame - 若必须传
DataFrame，确保它不含不可序列化字段（如pd.Series.plot对象、io.StringIO实例） - 用
functools.partial绑定固定参数时，别绑定DataFrame或函数内闭包变量，改用显式参数传入
apply_async 和 map 哪个更适合 Pandas 分块处理
map 简单但阻塞等待全部完成；apply_async 可并发提交 + 手动收集结果，更灵活，也更容易加超时和错误捕获。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
apply_async配合result.get(timeout=60)，防止某个子任务卡死拖垮整体 - 别在子进程中调用
pd.read_csv—— 每次都打开文件、解析 header，IO 开销大；应提前读好，再按行索引切片传入 - 如果每块数据量小（concurrent.futures.ProcessPoolExecutor，API 更清晰，异常堆栈也更可读
为什么开了 8 个进程，CPU 却只跑 20%？
根本不是进程数问题，而是 Pandas 内部大量操作（如 groupby、merge、apply）默认启用多线程（通过 numexpr 或 OpenBLAS），和你的 multiprocessing 形成资源争抢，反而降低吞吐。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 启动子进程前，强制关掉 Pandas 的并行后端：
import os; os.environ['NUMEXPR_NUM_THREADS'] = '1'; os.environ['OMP_NUM_THREADS'] = '1' - 子进程入口函数开头加
import pandas as pd; pd.options.mode.chained_assignment = None，避免警告触发锁 - 用
psutil.Process().cpu_affinity([i])绑定每个子进程到不同 CPU 核（需 Linux/macOS），减少上下文切换
怎么安全地把子进程结果拼回一个 DataFrame
直接用 pd.concat(list_of_results) 很危险：如果某子进程返回空 DataFrame、列顺序不一致、或 dtypes 强制转换失败（比如一列在部分块里是 int64，另一块是 float64），concat 会静默降级或报错。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有子进程返回统一结构的字典：
{'data': ndarray, 'columns': list, 'index': array}，主进程用pd.DataFrame构造，不依赖自动推断 - 若必须返回
DataFrame，在子进程里加校验：assert set(df.columns) == expected_cols and len(df) > 0 - 拼接前先统一 dtypes：
df.astype(common_dtypes, errors='ignore')，其中common_dtypes是主进程预估的各列最终类型
真正卡住性能的，往往不是进程数或切分逻辑，而是子进程里没关掉 Pandas 自带的线程池、或者忘了清理 matplotlib 后端——这些细节不打日志根本看不出来。
