onMessage 中 echo 不显示是因为 worker 进程 stdout 与 CLI 终端分离，尤其 daemonize=true 时被重定向至 /dev/null；应改用 error_log() 配合 log_file 和 log_level=5 调试。
onMessage 里的 echo 输出根本不会显示在 CLI 窗口
PHP 的 onMessage 是 Swoole WebSocket 服务器的回调函数，运行在 worker 进程中；而 CLI 启动时的标准输出（stdout）默认绑定的是主进程的控制台。worker 进程是 fork 出来的子进程，echo 或 var_dump 不会直接刷到你敲命令的那个终端里——尤其在守护进程模式（daemonize => true）下，stdout 甚至被重定向到了 /dev/null。
常见错误现象：onMessage 里写了 echo "hello"，启动服务后发消息，CLI 窗口完全没反应，以为代码没执行。
- 使用场景：调试 WebSocket 消息处理逻辑，比如想确认是否进到了
onMessage、参数是否正确 - 真正有效的做法是改用
Swoole\Coroutine::writeStdout()（协程环境）或error_log()/file_put_contents(..., FILE_APPEND) - 如果启用了
log_file配置（如'log_file' => '/tmp/swoole.log'），error_log()内容会自动落盘，比echo可靠得多
想实时看到 onMessage 日志？别依赖 echo，用 error_log + tail -f
error_log() 是最轻量、最兼容的调试输出方式，它绕过 stdout/stderr 的进程继承问题，直接走 PHP 的日志通道，Swoole 默认会把这类日志写入配置的 log_file（若未配置，则可能落到系统 syslog 或 stderr，但不可靠）。
实操建议：
- 启动前确保 server 配置里有
'log_file' => '/tmp/swoole.log'，且目录可写 - 在
onMessage里写error_log("onMessage received: " . json_encode($frame->data)); - 另开一个终端执行
tail -f /tmp/swoole.log，发 WebSocket 消息就能实时看到 - 避免用
print_r($frame, true)直接拼字符串——$frame是对象，可能触发不可序列化报错；优先用$frame->data或json_encode((array)$frame)
CLI 下 debug 卡住？检查 daemonize 和 log_level 配置
即使加了 error_log，也可能看不到输出，根源常出在两个配置上：
-
daemonize => true：开启后进程彻底脱离终端，所有 stdout/stderr 被关闭，error_log若没配log_file就直接丢弃 -
log_level => SWOOLE_LOG_WARNING（或更高）：Swoole 默认日志级别是WARNING，而error_log()发出的是NOTICE级别，会被过滤掉 - 解决办法：开发阶段设
'daemonize' => false+'log_level' => SWOOLE_LOG_DEBUG，再配合log_file - 注意
SWOOLE_LOG_DEBUG值为5，不是字符串，写错会导致配置不生效
协程环境下 echo 仍无效，但 writeStdout 可用（需 5.0+）
如果你用的是 Swoole v5.x 且启用了协程（enable_coroutine => true），可以尝试 Swoole\Coroutine::writeStdout()，它能在协程内安全向主进程的 stdout 写内容（前提是没 daemonize）。
示例：
Swoole\Coroutine::writeStdout("onMessage: " . $frame->data . "\n");
但要注意：
- 该函数仅在协程内可用，
onMessage回调本身就在协程上下文中（v4.4+ 默认启用），所以能用 - v4.x 不支持此函数，强行调用会报
Call to undefined method - 即便能打印，也只在非 daemonize 模式下可见；一旦
daemonize => true，依然看不到
onMessage 时最容易忽略的，其实是 log_level 的数值含义和 daemonize 对整个 I/O 环境的切断效应——不是代码没跑，是日志被静默吞掉了。 
