epoll实例通过epoll_create1(epoll_cloexec)创建，该调用在内核中初始化红黑树和就绪链表以管理监控的fd；flags必须设为epoll_cloexec防止fork子进程时fd泄漏，否则多进程下易引发连接hang住或epoll_wait阻塞失败。
epoll 实例怎么创建？epoll_create1 的 flags 不能随便填
Swoole 在初始化 Reactor 线程时，会调用 epoll_create1 创建内核事件实例。这个调用不是“创建就完事”，flags 参数直接影响资源安全：必须传 EPOLL_CLOEXEC，否则 fork 子进程（比如启动 TaskWorker）后，子进程会继承该 epoll fd，而父进程退出时可能没显式 close()，导致 fd 泄漏甚至后续 epoll_wait 阻塞失败。
常见错误是传 0 或忽略该参数——这在单 Worker 场景下可能不暴露问题，但一旦启用多进程模型（worker_num > 1），就会出现偶发性连接 hang 住、新连接无法接入的现象。
验证方式很简单：lsof -p $PID | grep epoll，如果看到多个重复的 epoll fd，基本就是 EPOLL_CLOEXEC 缺失导致的。
swoole_event_add 底层干了什么？不是简单注册回调
调用 swoole_event_add 时，Swoole 并不只是把 PHP 回调函数塞进某个哈希表。它实际做了三件事：
- 调用
epoll_ctl(EPOLL_CTL_ADD)，将 socket fd 注册进 epoll 实例，并设置监听事件（如EPOLLIN/EPOLLOUT） - 在用户态维护一份 fd → 回调函数指针 + 上下文结构体的映射表（
Reactor->event_map） - 为该 fd 分配或复用一个
ReactorFd结构体，记录其读写缓冲区、超时时间、是否启用边缘触发等元信息
所以你不能在协程里反复调用 swoole_event_add 同一个 fd —— 它不会自动去重，重复注册会触发内核报错 EEXIST，而 Swoole 默认不检查该错误码，最终表现为回调静默丢失。
为什么 epoll_wait 阻塞时 CPU 是 0%？这不是“空转”
很多人误以为 “阻塞 = 浪费 CPU”，其实 epoll_wait 在无事件时是真正让出 CPU 的系统调用：它把当前线程挂起，交还给调度器，内核不会轮询，而是等网卡中断、定时器到期或信号到来时才唤醒。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
这个行为直接决定了 Swoole Reactor 线程的吞吐天花板：单个 Reactor 线程能支撑数万并发连接，正是因为它的“等待”是零开销的。但这也带来一个硬约束——任何在 epoll_wait 前/后插入的同步耗时操作（比如在事件回调里执行 file_get_contents 或未协程化的 Redis get），都会拖慢整个事件循环，让所有连接感知到延迟。
换句话说：epoll_wait 很轻，但它前面和后面的代码，必须一样轻。
水平触发（LT）为什么是默认？边缘触发（ET）在 Swoole 里几乎不用
Swoole 的 ReactorEpoll 模块默认使用水平触发（EPOLLLT），因为 LT 对应用层更友好：只要 fd 可读，每次 epoll_wait 都会通知，哪怕你只读了一半数据；而 ET 要求你一次性读完（直到 recv 返回 EAGAIN），否则后续再无通知。
ET 看似高效，但在 PHP 协程环境下极易出错：协程可能在读取中途被调度出去，缓冲区残留数据无法触发下一次通知，连接就此卡死。Swoole 没有对 ET 做协程安全封装，也不推荐手动切换 —— 除非你完全掌控 fd 生命周期且不依赖任何协程 I/O 函数。
顺带一提：epoll_ctl 注册时没传 EPOLLET，那就一定是 LT；别信某些文档说“Swoole 自动适配”，它不自动，它固定。
真正容易被忽略的点在于：epoll 不是魔法，它只是把“等谁来”这件事交给内核；而“等来了之后怎么做”，全靠你在回调里写的那几行 PHP/C 代码——它们是否协程安全、是否释放资源、是否处理边界条件，才是压垮高并发服务的最后一根稻草。
