clean_texts() 的 n_jobs 参数需根据数据规模合理设置：少于5k条文本不建议并行；Jupyter中避免n_jobs=-1，推荐设为2或4；直接传Series.tolist()而非先转list。
clean_texts() 的 n_jobs 参数到底怎么用才不白配
直接设 n_jobs=-1 并不总能加速，尤其当文本列表太短（比如少于 1000 条）或单条文本极长时，进程启动开销反而压过收益。实际生效前提是：任务可并行切分 + 每个子任务耗时明显大于调度成本。
推荐做法：
- 先用
len(raw_texts)粗估规模：>5k 条再考虑开启并行 - 避免在 Jupyter Notebook 中直接用
n_jobs=-1，子进程可能无法正确继承 notebook 的运行环境，改用n_jobs=2或n_jobs=4更稳 - 若原始数据是 pandas
Series，别先转成 list 再传给clean_texts()—— 它内部会重新转回数组，多一次拷贝；直接传series.tolist()即可
map + multiprocessing.Pool 比 clean-text 自带并行更灵活吗
是的，但代价是手动管理粒度和异常。当你需要混合清洗逻辑（比如一部分走 clean_texts()，另一部分要调用自定义函数或外部 API），multiprocessing.Pool.map() 更可控。
关键注意点：
立即学习“Python免费学习笔记（深入）”；
- 函数必须可序列化（不能是 lambda 或嵌套函数），建议定义在模块顶层
- 不要在 worker 进程里重复 import
cleantext或 re 编译正则——提前在主进程编译好，作为参数传入 - 遇到 UnicodeDecodeError 时，
Pool默认静默吞掉异常，务必加try/except并显式print()或写日志，否则会卡死且无提示
为什么用 map 处理大文件时内存还在涨
因为 map() 默认一次性把整个输入迭代器展开为 list 加载进内存，哪怕你用的是生成器。真正节省内存得用 imap() 或 imap_unordered()。
实操建议：
- 读文件时用生成器逐行 yield：
def read_lines(filename): with open(filename) as f: for line in f: yield line.strip() - 传给
pool.imap(clean_func, read_lines('big.txt'), chunksize=1000)，chunksize控制每次发给 worker 的批量大小，1000 是经验值，太大易 OOM，太小调度开销高 - 结果别存 list，边处理边写磁盘：
for cleaned in pool.imap(...): output_file.write(cleaned + '\n')
clean-text 和手写 re.sub + map 组合，哪个更快
取决于清洗项数量。如果只做 1–2 种简单替换（如去 URL、去空格），纯 re.sub() 配合预编译 Pattern + imap 通常比 clean_texts() 快 1.2–1.5 倍——它省掉了参数校验、类型转换、默认选项合并等额外逻辑。
但一旦清洗项超过 5 个（比如同时去 URL、邮箱、电话、IP、emoji、多余空白、HTML 标签），clean_texts() 的 C 扩展底层优化开始起效，整体更稳，且代码量少一半。
容易被忽略的一点：clean-text 的 no_emoji=True 实际调用的是 regex 库（非标准 re），对 Unicode 表情支持更好；而自己写 re.sub(r'[\U0001F600-\U0001F64F\U0001F300-\U0001F5FF...]', '') 很难覆盖全，还容易因 Python 版本差异出错。
