PHP 里没有原生事件循环，别硬套 Node.js 那套
PHP 默认是同步阻塞模型，event 扩展或 Swoole 是少数能真正跑事件循环的路径。直接用 pcntl_fork 或 stream_select 模拟“事件驱动”，往往只是轮询加回调，本质还是同步，性能和可维护性反而更差。
常见错误现象：call_user_func_array 套一堆监听器，但所有回调都在一次 HTTP 请求生命周期内顺序执行，没并发、没延迟、没事件队列——这叫“观察者模式”，不是事件驱动。
- 真需要事件驱动：上
Swoole\Event::wait()或ext-event的event_base_loop() - 只是想解耦逻辑：用
Symfony\Contracts\EventDispatcher\EventDispatcherInterface这类轻量接口就够了 - Web 场景下混用 CLI 和 FPM：Swoole 的事件循环在 FPM 下不生效，
Event::loop()会直接报错或静默失败
Swoole 的 Event::wait() 怎么安全启动
Swoole\Event::wait() 启动的是单线程事件循环，不能在 Web 请求中调用（比如在 Laravel 控制器里执行），否则整个请求会卡死。它只适合长期运行的 CLI 进程，比如消息监听、定时任务调度。
使用场景：后台服务监听 Redis Pub/Sub、处理 WebSocket 心跳、聚合多个 HTTP API 响应。
立即学习“PHP免费学习笔记（深入）”；
- 必须在
cliSAPI 下运行，php -S或php-fpm中调用会直接退出或抛出SWOOLE_ERR - 注册回调前确保资源已就绪，比如
stream_socket_client返回的 socket 要设为非阻塞：stream_set_blocking($fd, false) - 不要在回调里做耗时操作，否则阻塞整个事件循环；CPU 密集型任务得丢给
ProcessPool或TaskWorker
示例（简化）：
Swoole\Event::add($redis_fd, function($fd) {
$data = fread($fd, 1024);
// 处理数据...
}, null, SWOOLE_EVENT_READ);
注意：$redis_fd 必须是流资源，且由 stream_socket_client 或 socket_create 创建并显式设为非阻塞。
用 pcntl_signal 捕获信号算不算事件驱动
算，但非常有限。它只响应 OS 信号（如 SIGUSR1、SIGHUP），不是通用事件总线。而且 PHP 的信号处理有严重限制：回调函数里不能调用大多数扩展函数（比如 mysqli_query、curl_exec），也不能触发 GC 或抛出异常。
容易踩的坑：
-
pcntl_signal_dispatch()必须在主循环里主动调用，否则信号不会被处理（PHP 不自动 dispatch） - 在
fastcgi_finish_request()后发信号，回调可能在请求结束后才执行，导致$_SERVER、$GLOBALS等上下文已销毁 -
pcntl_fork子进程继承父进程的信号处理器，但子进程 exit 后父进程若没pcntl_wait，会留僵尸进程
Composer 包里常见的“事件”其实是钩子，不是事件循环
像 composer install 触发的 post-install-cmd，或 Laravel 的 booted 回调，都是同步钩子（hook），执行时机固定、无调度、无优先级、无异步能力。它们依赖框架/工具自身流程控制，和事件驱动编程模型无关。
混淆点在于命名：很多包把 Event 当作“通知机制”来用，但底层仍是 foreach ($listeners as $l) $l($event) —— 没有事件队列、没有 I/O 多路复用、没有延迟投递。
- 如果要跨进程/跨机器广播事件，得靠外部中间件（Redis、RabbitMQ），PHP 代码只负责发消息，不负责消费循环
- 用
spatie/event-sourcing这类库，核心是领域事件持久化，不是运行时事件分发 - 别试图用
register_shutdown_function模拟事件，它只在脚本结束时触发一次，不可靠也不可控
真正难的不是写个 dispatch 方法，而是决定哪些逻辑该进事件循环、哪些该保留在同步流程里——边界模糊时，先压测再选型，别提前抽象。
