asyncio.run() 报 runtimeerror 是因它自动创建并关闭事件循环，不可重复调用；jupyter 中应直接 await，子线程需手动新建 loop；threadpoolexecutor 需用上下文管理器或显式 shutdown；multiprocessing.picklingerror 源于函数不可序列化；gather 与 wait 在错误处理和返回结构上差异显著。
asyncio.run() 为什么一用就报 RuntimeError: Event loop is closed
因为 asyncio.run() 内部会创建、运行并关闭事件循环，不能在已运行的事件循环中重复调用。常见于 Jupyter、FastAPI 启动脚本、或多次调用该函数的测试代码里。
- 真正需要复用事件循环时，改用
asyncio.get_event_loop().run_until_complete()（注意：Python 3.10+ 推荐用asyncio.get_running_loop()） - Jupyter 中直接 await 即可，不用包一层
asyncio.run() - 若在子线程中启动，必须手动新建事件循环：
loop = asyncio.new_event_loop()，再loop.run_until_complete()
concurrent.futures.ThreadPoolExecutor 提交任务后不执行
本质是没显式调用 shutdown(wait=True) 或没获取 Future 结果，导致主线程退出、线程池被强制终止。
- 务必用
with ThreadPoolExecutor() as executor:上下文管理器，它自动等待完成 - 手动管理时，提交完所有任务后要调用
executor.shutdown(wait=True) - 如果只调用
submit()但不调用future.result()或as_completed()，任务可能根本没开始执行（取决于线程调度和 GC 行为） - 注意：
max_workers=None在不同 Python 版本含义不同（3.8+ 是min(32, os.cpu_count() + 4)），别假设它等于 CPU 核心数
multiprocessing.Pool.map() 报 PicklingError
因为子进程无法序列化闭包、lambda、类实例方法或定义在 __main__ 模块顶层之外的函数。
- 确保目标函数是模块级普通函数，且定义在
if __name__ == '__main__':之外 - 避免传入嵌套函数、
functools.partial包装过的对象（除非其参数本身可序列化） - Windows/macOS 上 multiprocessing 默认用 spawn 启动方式，比 fork 更严格；Linux 下 fork 虽能绕过部分限制，但不可靠，别依赖
- 替代方案：用
concurrent.futures.ProcessPoolExecutor，错误提示更清晰；或改用dill库替换 pickle（但会引入额外依赖和性能开销）
asyncio.gather() 和 asyncio.wait() 的选择困惑
两者都并发执行协程，但错误处理和返回结构差异很大，选错会导致异常被吞掉或结果难解析。
-
asyncio.gather(*coros)：按顺序返回结果列表，任一协程抛异常则整个gather立即失败（除非加return_exceptions=True） -
asyncio.wait(coros, return_when=...)：返回已完成/未完成的set，不自动展开结果，需手动调用task.result()，异常不会中断其他任务 - 批量请求 API 场景优先用
gather（简单直接）；需要控制超时粒度、或容忍部分失败时用wait - 注意：
gather不等价于 “并发执行”，它只是并发调度；真正的 I/O 并发仍取决于底层是否真正异步（比如aiohttpvsrequests）
多任务不是加个 async 或开个 Process 就完事——数据怎么传、异常怎么冒泡、资源怎么回收，每个环节都卡在具体函数的行为细节里。最容易忽略的是事件循环生命周期、对象序列化边界、以及“并发”在不同层级的真实含义。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
