libuv框架下uv_timer与uv_idle回调互相影响的原因及正确用法

核心问题是你对libuv的运行模型存在误解：

1. libuv的事件循环默认是单线程串行执行的，所有注册到同一个loop上的句柄回调，都在调用uv_run的线程内排队执行，不存在“不同句柄跑独立线程、互不干扰”的机制。只要某一个回调没有执行结束返回，整个事件循环就会被完全卡住，没有机会处理其他任何就绪的回调——不管是定时器、IO事件还是idle任务，都得等当前回调跑完才能轮到。
2. uv_idle句柄的触发逻辑是：每次事件循环迭代时，只要没有待处理的高优先级事件，就会执行注册的idle回调。你在idle回调里直接调用sleep(5)，相当于强行霸占事件循环线程5秒，这期间哪怕定时器早就到了设定的触发时间，循环也根本抽不出空去执行cb2，必须等idle回调执行完返回，循环才能进入下一轮处理到期的定时器任务，自然就出现了“aaa输出后长时间卡住、之后才输出bbb”的现象。
3. 你用到的sleep是典型的阻塞式系统调用，它不会把CPU控制权交还给事件循环，只会一直占着线程直到休眠结束，这和libuv的异步设计逻辑完全冲突。libuv的“异步”指的是它可以在单线程内通过非阻塞IO+事件通知的方式同时调度大量IO、定时任务，不需要为每个任务开单独线程，但这种能力的前提是所有回调都能快速返回、不阻塞线程，一旦回调里出现长时间阻塞逻辑，异步调度能力会直接失效。

• 绝对不要在任何libuv回调中执行长时间阻塞操作，包括但不限于sleep类休眠调用、死循环、耗时超过数毫秒的同步计算、阻塞式IO。这类操作会直接卡死整个事件循环，导致所有定时、IO任务的触发时间完全失控。
• 耗时任务按场景选择正确的处理方式：
  • 可拆分的轻量耗时任务：将任务拆成多个小步骤，每次回调只执行一个小步骤就立刻返回，通过idle/prepare/check句柄调度后续步骤执行，保证单次回调执行时间极短，不阻塞循环
  • 不可拆分的重耗时/阻塞任务：使用libuv提供的uv_queue_work接口，将阻塞任务提交到libuv内置的后台线程池执行，任务执行完成后再将结果回调抛回主事件循环处理，全程不会阻塞主循环的其他任务调度
• 你当前示例代码里还有一处逻辑问题：uv_run返回后写的while(1);是死循环，后面的uv_loop_close和free(loop)永远不会被执行，属于无效死代码。

内容的提问来源于stack exchange，提问作者Defoe Victor