主线程自动创建事件循环，子线程需手动三步初始化：new_event_loop() → set_event_loop() → run_until_complete()；因asyncio用threading.local()隔离各线程_loop，非主线程不触发自动创建逻辑。
因为 asyncio 的事件循环默认只在主线程自动创建，子线程里根本没“配发”事件循环——asyncio.get_event_loop() 在非主线程调用时，不会自动新建，而是直接抛 RuntimeError: There is no current event loop in thread 'Thread-X'。
为什么主线程有循环，子线程却没有？
asyncio 内部用 threading.local() 管理事件循环，每个线程的 _local._loop 是隔离的。源码里明确写了：只有当前线程是 threading._MainThread 且还没设置过循环时，get_event_loop() 才会调用 set_event_loop(new_event_loop())；其他线程一律跳过这步，直接报错。
这意味着：
- 你在主线程调
asyncio.get_event_loop()→ 安全返回一个 loop - 你在
Thread-1里同样调 → 报错，哪怕只差一行代码 -
asyncio.run()也一样，它内部仍依赖get_event_loop()，子线程里照样崩
子线程里启动事件循环的三步必须做全
不能只写 asyncio.new_event_loop() 就完事。漏掉任意一步，都会卡在 get_event_loop() 或后续调度上：
- 先调
asyncio.new_event_loop()创建新实例 - 再用
asyncio.set_event_loop(new_loop)绑定到当前线程本地存储 - 最后才能安全调
asyncio.get_event_loop()或new_loop.run_until_complete(...)
常见错误写法：loop = asyncio.new_event_loop(); loop.run_until_complete(...) —— 这样没调 set_event_loop()，后续如果代码里又出现 get_event_loop()（比如某些库内部调用），依然会崩。
用 run_in_executor 时为什么通常不报这个错？
因为 run_in_executor 是从**主线程的事件循环**发起的，它只是把同步函数丢进线程池执行，自己不在线程池里跑异步代码。真正出问题的是：你在线程池 worker 函数里主动写 asyncio.get_event_loop() 或试图 await 协程。
如果你需要在线程里跑协程，正确做法不是在线程里调 run_in_executor，而是：
- 用
asyncio.run_coroutine_threadsafe(coro, loop)，把协程“投递”给主线程的 loop 执行（loop 必须正在运行） - 或者改用
asyncio.to_thread()（Python 3.9+），它封装了线程内事件循环的创建逻辑，但仅适用于单次协程调用 - 避免在
ThreadPoolExecutor的 worker 中手动管理 loop —— 架构上容易绕晕，也难清理资源
Jetson 或嵌入式设备上特别要注意什么？
这类设备内存小、Python 版本常偏旧（比如仍用 3.8/3.9），而 asyncio.new_event_loop() 创建的 loop 默认不支持 add_signal_handler（Linux 下），如果协程里用了 signal 相关逻辑，会额外报错；另外 loop 关闭不彻底（比如忘了 loop.close()）容易导致 fd 泄漏，在长期运行的服务中逐渐耗尽资源。
所以实际部署时：
- 子线程 loop 启动后，务必在退出前调
loop.close() - 避免频繁创建/销毁 loop，尤其在高频触发的线程中（比如每帧都开个新线程推 WebSocket）
- 优先考虑用单线程 +
asyncio.to_thread()或run_in_executor调用阻塞操作，而不是硬上多线程+异步混合架构
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
