任务拆分过细会因调度开销导致性能下降：CPU密集型建议单批≥10ms（如100–1000条），IO密集型单批不低于10次请求；map()自动分块而submit()需手动聚合；避免闭包引用大对象引发内存爆炸；不同执行器（线程/进程/asyncio）最优粒度差异显著，须实测确定。
任务拆分太细会导致调度开销压垮性能
Python 里用 concurrent.futures 或 asyncio 做批量任务时，不是越小越好。比如把 10 万条记录拆成 10 万个单条任务，线程/协程创建、上下文切换、结果收集的开销会远超实际计算时间。
- CPU 密集型任务：单个子任务建议耗时 ≥ 10ms，通常按 100–1000 条/批较稳
- I/O 密集型（如 HTTP 请求）：可更细，但单批别低于 10 次请求，避免 TCP 连接反复建立
- 使用
ThreadPoolExecutor.submit()时，提交 10 万次调用比提交 100 次（每批千条）慢 3–5 倍，实测过
map() 和 submit() 的批处理行为差异很大
executor.map() 是同步批处理接口，内部已做 chunking；submit() 是逐个提交，完全由你控制粒度——这点常被忽略，导致误以为“用了线程池就自动优化了”。
-
map(func, items)默认把items分块传给工作线程，块大小由chunksize参数控制，默认是len(items) // (4 * worker_count) - 手动用
submit()时，若循环里每次只传一个参数，等于放弃 chunking，必须自己聚合：executor.submit(process_batch, batch_list) - 异步场景下，
asyncio.gather()对上千个await任务也会卡顿，应改用asyncio.as_completed()+ 批量create_task()
内存爆炸往往源于“假拆分”
表面拆了任务，但数据没真正切片，所有子任务仍引用同一份大对象（比如全局 df 或 session），结果每个线程都拷贝一份，OOM 就在所难免。
- 别在闭包里直接引用大变量：
executor.submit(lambda x: heavy_work(x, big_data), item)——big_data会被序列化进每个任务 - 正确做法：把依赖显式传入，且只传必要字段，或用
multiprocessing.Manager共享只读数据 - Pandas 场景常见坑：
df.iloc[start:end]是视图，但传给子进程会触发隐式拷贝；改用df.iloc[start:end].copy()明确控制，或用swifter/dask替代手工拆分
不同后端对“合理粒度”的定义完全不同
同一个任务，在 ThreadPoolExecutor、ProcessPoolExecutor、asyncio 下的最优拆分点可能差一个数量级。
立即学习“Python免费学习笔记（深入）”；
- 线程池：适合 I/O，单批 50–500 次请求较稳；CPU 密集型几乎无加速，还可能因 GIL 变慢
- 进程池：适合 CPU 密集型，但进程启动成本高，单批至少 100ms 计算量才划算；注意
max_workers别设超过os.cpu_count() - asyncio：无进程/线程开销，但要求所有 I/O 都是异步的；混用
requests这类同步库会阻塞整个事件循环，看似拆了，实则串行
真实项目里，粒度不是靠理论算出来的，得用 time.perf_counter() 在不同 batch_size 下跑三轮，看吞吐和内存峰值拐点在哪里。没人能替你跳过这步。
