c++ libuv事件循环 c++如何使用libuv进行网络和文件io-C++-PHP中文网

libuv事件循环需手动启动，uv_run()不会自动返回；所有handle、request、buffer生命周期须自行管理，避免野指针、泄漏或崩溃。

c++ libuv事件循环 c++如何使用libuv进行网络和文件io

很多人写完 uv_tcp_init()、uv_fs_open() 就以为 IO 会立刻跑起来，结果程序直接退出——因为没调 uv_run()，或者调了但传了错误的 mode。libuv 的事件循环是显式驱动的，不启动就等于没通电。

实操建议：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

uv_run(loop, UV_RUN_DEFAULT) 是最常用模式，它会阻塞直到没有活跃 handle 或 request，适合主循环
如果只是想处理一次就返回（比如做异步文件读取后继续其他逻辑），用 UV_RUN_ONCE，但要注意：它只轮询一次，哪怕还有 pending request 也会退出
别在 uv_run() 前释放 uv_loop_t*，也不要在回调里调 uv_loop_close() 后再进 uv_run()，会 crash
网络监听要先 uv_tcp_bind() 再 uv_listen()，漏掉 bind 会导致 UV_EADDRNOTAVAIL

libuv 不帮你 malloc/free 连接相关的结构体，所有 uv_handle_t 和 uv_req_t 都是栈或堆上由你分配的裸内存。一旦回调触发，handle 可能已被关掉，但 request 结构体还在——这时候访问已释放的 uv_connect_t* 就是野指针。

实操建议：

libuv 的文件操作是真正的异步（底层用线程池模拟），uv_fs_read() 提交后立即返回，但内核可能几毫秒后才真正把数据拷到你给的 buffer 里。如果 buffer 是栈变量或提前 delete 的堆内存，read_cb 里读到的就是垃圾。

实操建议：

用 uv_buf_t 包装 buffer 时，确保其指向的内存生命周期 ≥ 整个异步读过程
常见做法：把 buffer 和 uv_fs_t request 一起 new 出来，绑在同一个结构体里，在 read_cb 末尾统一 delete
uv_fs_open() 的 flag 要明确，比如 UV_FS_O_RDONLY，别直接传数字 0；Windows 下不支持 O_NONBLOCK，libuv 已屏蔽
同步文件操作（如 uv_fs_read_sync）会阻塞线程，仅用于初始化或调试，别在 event loop 线程里用

libuv 的 loop 不是线程安全的，不能在 worker 线程里直接调 uv_tcp_write() 或 uv_fs_write()。但你可以用 uv_async_send() 或 uv_queue_work() 把任务“转交”给 loop 所在线程执行。

实操建议：

主线程创建 loop，worker 线程通过 uv_async_t 发信号，async_cb 在 loop 线程里执行真正的 IO 操作
uv_queue_work() 更适合耗时计算或阻塞系统调用，它会把 work_cb 交给线程池，done_cb 回到 loop 线程——注意 done_cb 里才能安全操作 handle
别在 worker 线程里调 uv_run()，loop 必须且只能由一个线程运行
跨线程访问自定义数据时，仍需加锁（libuv 不管你的业务数据），uv_async_t 本身不带 payload，要自己用成员变量或 closure 传参

事情说清了就结束。最难的不是调哪个函数，而是始终记住：libuv 暴露的是 C 风格的裸资源管理接口，所有 handle、request、buffer 的生命周期，都得你自己画清楚边界。