epoll不是c++标准库组件，而是linux内核系统调用，需通过c接口epoll_create1、epoll_ctl、epoll_wait使用，头文件为；需注意错误处理、et/lt模式选择、内存生命周期及事件循环完整性。
epoll 不是 C++ 标准库的一部分，C++ 本身没有 epoll —— 它是 Linux 内核提供的系统调用，必须通过 C 风格的 syscall 或封装好的 C 接口使用。
怎么在 C++ 里调用 epoll 函数
你得直接用 Linux 的 C 接口：epoll_create1、epoll_ctl、epoll_wait。C++ 编译器完全兼容这些函数，头文件是 <sys></sys>，链接不需要额外库（内核接口，无 libc 依赖）。
常见错误现象：epoll_create1 返回 -1 且 errno == ENOSYS —— 这说明内核版本太低（
- 必须 #include
、 、 、 -
epoll_create1(0)比旧的epoll_create更安全，推荐始终传 0 - 监听 socket 必须设为非阻塞（
fcntl(fd, F_SETFL, O_NONBLOCK)），否则epoll_wait可能不触发可读，或read卡住 - 别把
epoll_fd当普通 fd 传给close()以外的任何系统调用（比如误塞进select）
epoll_ctl 的 EPOLL_CTL_MOD 容易出错
很多人以为 EPOLL_CTL_MOD 只改事件掩码，其实它要求 fd 已经在 epoll 实例中注册过；如果没注册就用 MOD，会返回 ENOENT。
立即学习“C++免费学习笔记（深入）”；
使用场景：比如连接刚建立时只监听可读，收到请求后想加监听可写（如响应大文件），就得用 MOD 更新 events 字段。
- 第一次注册必须用
EPOLL_CTL_ADD，不能跳过 -
epoll_event结构体里的data.fd和data.ptr二选一用；混用或不初始化容易导致epoll_wait返回脏数据 - 修改事件时，
epoll_event.events必须显式写出全部要监听的事件（比如原来有EPOLLIN，现在要加EPOLLOUT，就得写EPOLLIN | EPOLLOUT，不是只写EPOLLOUT）
epoll_wait 返回后怎么安全处理就绪事件
返回值是就绪事件数量，但 epoll_event 数组里每个元素的 data 字段内容取决于你注册时填的是 fd 还是 ptr —— 这个差异直接影响你怎么取上下文。
性能影响：如果每次 epoll_wait 后都遍历所有就绪项做 read/write，但某个连接一次只读到一半包，又没继续循环处理，就会丢事件或卡死。
- 永远检查
ret > 0再遍历，ret == 0表示超时（如果你设了 timeout），ret == -1要看errno（EINTR可重试，EBADF说明 fd 被提前关了） - 对每个就绪 fd，必须循环
read直到返回-1且errno == EAGAIN（非阻塞语义），不能只读一次 - 如果用
data.ptr存自定义结构体指针，确保该内存生命周期覆盖整个 epoll 生命周期（别在连接关闭后还让 epoll 持有悬垂指针）
为什么不用 epoll 封装库（如 libev、libuv）
不是不能用，而是封装库会隐藏关键细节：比如它们默认帮你做边缘触发（ET）还是水平触发（LT）、怎么管理 fd 生命周期、buffer 怎么复用。一旦出问题，你得钻进封装层才能定位。
兼容性影响：libuv 跨平台，但在 Linux 上实际仍走 epoll；而手写的话，你可以严格控制 ET/LT 模式、避免不必要的 epoll_ctl 调用（比如反复 MOD 同一个 fd），这对百万连接场景很关键。
- 如果你只需要跑在 Linux 服务器上，且对延迟和连接数敏感（比如游戏网关、实时消息代理），手写更可控
- 如果项目要兼顾 macOS（kqueue）或 Windows（IOCP），或者开发节奏紧，libuv 是更省心的选择
- 别为了“高效”强行手写——没测过
epoll_wait在 10w 连接下的唤醒延迟、没压测过 buffer 分配策略，所谓高效只是幻觉
真正难的不是调几个函数，是理解每个 epoll_ctl 调用背后内核状态的变化，以及如何让用户态逻辑和内核事件通知节奏对齐。漏掉一次 EAGAIN 判断，或少清一个 EPOLLET 标志，线上就可能挂半天。
