为何手动创建asyncio事件循环需调用set_event_loop，子进程行为才正常？

这个问题核心在于asyncio内部的事件循环绑定逻辑，咱一步步拆解清楚：

1. asyncio的「当前事件循环」是隐形绑定 #

asyncio在每个线程里都维护了一个"当前事件循环"的隐式绑定，get_event_loop()默认返回的就是这个绑定的循环。当你手动创建SelectorEventLoop但没调用set_event_loop(loop)时，这个新循环并不会自动成为当前线程的默认循环——此时如果有代码（哪怕是asyncio内部的代码）调用get_event_loop()，拿到的会是asyncio自动创建的另一个默认循环。

2. 子进程操作依赖「当前事件循环」 #

你调用create_subprocess_exec时虽然显式传了loop参数，但子进程创建后的状态监听逻辑（比如等待子进程退出的process.wait()），内部有些步骤会依赖当前线程的默认事件循环，而不是你传入的那个loop。

举个实际场景：子进程启动后，asyncio需要把进程的文件描述符注册到事件循环里，才能监听它的退出信号。如果当前默认循环不是你手动创建的那个，这个注册操作就会跑到自动生成的默认循环上——而你代码里用来run_until_complete的是自己创建的loop，它根本没在监听这个子进程的事件，自然就会出现行为异常：比如wait_for超时、process.returncode迟迟不更新，甚至程序卡住。

3. 结合你的代码看差异 #

比如你这么写（没调用set_event_loop）：

loop = SelectorEventLoop()
run_timeout(loop, foo(loop), 5)

此时foo里的create_subprocess_exec虽然接收了你传入的loop，但内部处理子进程事件时，还是会用get_event_loop()拿到的默认循环，导致你的手动loop和子进程事件完全脱节，最终要么超时，要么无法正确获取子进程的退出状态。

而加上set_event_loop(loop)之后：

loop = SelectorEventLoop()
set_event_loop(loop)
run_timeout(loop, foo(loop), 5)

当前线程的默认循环被替换成了你手动创建的那个，所有子进程相关的事件监听都会注册到这个loop上，process.wait()就能被正确驱动，程序行为完全符合预期。

简单总结：set_event_loop是把你手动创建的loop"扶正"成当前线程的默认循环，让asyncio内部所有依赖默认循环的操作都和它绑定，这样子进程的事件才能被你的loop正确处理。

内容的提问来源于stack exchange，提问作者Bailey Parker