swifter 默认不启用多进程，仅在数据量大且函数为cpu密集型时可能触发并行；强制使用需调用 .set_npartitions(n)，否则因序列化开销可能导致比pandas更慢。

swifter 本身不直接“借用多进程加速 apply”，它只是在底层自动选择最合适的并行后端（pandas 自带的单线程、dask、modin 或 multiprocessing），而是否启用多进程，取决于数据规模、函数类型和你的显式配置。默认情况下，小数据走单线程，大数据才可能触发多进程——但这个判断经常不准，容易让你误以为“没加速”。

swifter.apply() 为什么有时比 pandas.apply() 还慢？

根本原因在于 swifter 的预估开销机制：它会先用少量样本（默认前1000行）跑一次 apply，估算单线程耗时，再决定是否切分并行。如果函数本身极轻量（比如 lambda x: x + 1），序列化+进程启动+IPC通信的开销远超计算本身，结果就是越并行越慢。

• 函数必须是 CPU 密集型（如数值计算、字符串解析、日期转换），而非 I/O 或纯 Python 循环
• 数据量建议 > 50k 行且每行处理耗时 > 1ms，否则别强上多进程
• swifter 默认不启用 multiprocessing，需显式调用 .allow_dask_on_strings(enable=True) 或设 npartitions 才可能触发
• 若 DataFrame 含不可 pickle 的对象（如 lambda、嵌套类实例、数据库连接），swifter 会静默回退到单线程，且不报错

如何强制 swifter 使用 multiprocessing 后端？

不能靠 .apply(...).swifter.apply(...) 这种链式调用，必须在调用前设置后端。最可靠的方式是：

<pre class="brush:php;toolbar:false;">import swifter
import pandas as pd
<h1>强制使用 multiprocessing，指定进程数（不填则用 os.cpu_count()）</h1><p>df['new_col'] = df['col'].swifter.set_npartitions(4).apply(your_func)</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8054" title="python-parallelization"><img
														src="https://img.php.cn/upload/skill/000/000/081/179181013081932.jpg" alt="python-parallelization" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill8054" title="python-parallelization" class="overflowclass">python-parallelization</a>
													<p class="overflowclass">将顺序 Python 代码转换为并行/并发实现，用于在需要并行化 Python 代码、提升性能时使用。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill8054" title="python-parallelization" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>

• set_npartitions(n) 是关键：它让 <code>swifter 把 DataFrame 按行切分为 n 块，每块交由一个子进程处理
• 避免用 set_dask_scheduler('processes') —— 它依赖 dask，而 dask 对 pandas 对象支持不稳定，易出 PicklingError
• 若函数需要额外参数，用 lambda 包一层或改用 functools.partial，不要传入不可序列化的对象

swifter + multiprocessing 的典型报错与绕过方式

最常见的错误是 BrokenProcessPool 或 PicklingError: Can't pickle <function ...></function>，本质都是子进程无法反序列化主进程里的东西。

• 错误现象：AttributeError: Can't get attribute 'my_helper' on <module></module>
• 原因：函数定义在 if __name__ == '__main__': 外部，或用了局部定义/lambda/闭包
• 解决：把函数移到模块顶层，确保可被 pickle；检查是否引用了全局变量（如 CONFIG 字典），应改为显式传参
• 调试技巧：先用 pool = multiprocessing.Pool(); pool.apply(your_func, args=(df.iloc[0],)) 手动测试能否 pickle，再交给 swifter

比 swifter 更可控的替代方案：直接用 multiprocessing.Pool.map

当 swifter 行为不可预测、或你需要精确控制分块逻辑/错误处理/进度反馈时，绕过它直连 multiprocessing 反而更稳。

<pre class="brush:php;toolbar:false;">from multiprocessing import Pool
import numpy as np
<p>def process_chunk(chunk):
return chunk['col'].apply(your_func)  # 注意：这里仍是 pandas apply，但只作用于子块</p><p>if <strong>name</strong> == '<strong>main</strong>':
chunks = np.array_split(df, 4)  # 手动切分
with Pool(4) as p:
results = p.map(process_chunk, chunks)
df['new_col'] = pd.concat(results).values  # 拼回原顺序</p>

• 优势：完全掌控分块粒度、异常传播（map 报错即停，<code>map_async 需 get() 才暴露）、内存释放时机
• 注意：process_chunk 内不能修改原始 df，所有操作必须返回新 Series/DataFrame
• 若函数涉及共享资源（如写文件、更新数据库），必须加锁或改用 Queue 传递结果，避免并发冲突

真正难的不是调用 swifter，而是判断「当前这个 apply 是否值得并行」以及「并行后结果是否还对得上原始索引顺序」——这两点，swifter 不会替你确认，文档也不会提醒你。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！