status命令比ps更可靠，因它通过Unix socket读取主进程共享内存的实时数据，而非仅检查进程存在与否；失败时错误信息精准，且不干扰业务。
能执行 php start.php status 并返回带表格的输出，就说明 Workerman 已成功运行；否则大概率没起来，或通信链路断了。
为什么 status 命令比 ps aux | grep workerman 可靠
它不查进程“有没有”，而是真实连接主进程创建的 Unix socket（默认路径 /tmp/workerman.*.status），读取共享内存里的实时统计值。哪怕某个 worker 卡死在死循环里，只要 master 进程活着、socket 可读，status 就能返回结果。
- ps 看到的可能是残留 pid 或僵尸进程，误判率高
- status 失败时的错误信息更精准：
No pid file说明根本没启动；Can not connect to master process说明 master 挂了或 socket 权限/路径不对 - 该命令不 reload、不中断连接、不触发任何业务逻辑，是线上唯一安全的状态快照入口
status 报 “no pid file” 或连不上 socket 怎么办
这不是命令写错了，是启动环节出了问题。必须确认这三件事：
- 服务是否用
php start.php start -d启动（-d是关键，没加就无法生成管理 socket） -
start.php中是否修改过Worker::$pidFile路径？如果改了，status会去默认路径找 pid 文件，自然失败 -
/tmp/workerman.*.status*文件是否存在？stop 后又 start -d，旧 socket 残留会导致新进程绑定失败，需手动清理：rm /tmp/workerman.*.status* - 权限是否一致？root 启动的服务，普通用户执行
status会因 socket 属主和权限（应为 644）被拒绝 —— 统一用业务用户启动，或改Worker::$pidFile路径属主
看到 status 输出后，盯哪几项才说明“真在干活”
别只看有没有表格，重点观察这四个字段是否动态变化：
-
connections> 0 且随客户端接入有波动 → 连接层通了 -
total_request缓慢增长（哪怕每秒 1–2 次）→ 业务逻辑正在被触发 -
mem_usage稳定在几 MB（非 0 或飙升到几百 MB）→ 内存没泄漏也没卡死 -
state偶尔显示busy是正常的，但持续 >30 秒未变 → 很可能卡在同步阻塞操作（如未设超时的 PDO 查询、file_get_contents）
如果某 worker 的 connections 长期为 0 且 total_request 不动，大概率是它的 onMessage 或 onWorkerStart 里抛了未捕获异常，被 Workerman 静默吞掉后不再收新请求。
connections 命令不是 status 的增强版，而是另一类诊断工具
php start.php connections 只在 Workerman ≥ 3.5.0 且 TCP/UDP Worker 中生效，HTTP/WebSocket 默认不启用连接级统计。要让它输出连接时间、缓冲区等细节，得在 Worker 初始化时加一行：$worker->connection_class = \Workerman\Connection\TcpConnection::class;
- 大量连接
send_queue_size > 0且last_send_time长期不更新 → 客户端已断开但服务端没感知 - 输出里出现一堆
close_wait→ 很可能是onClose回调里做了同步耗时操作（如发 HTTP 请求、写日志），导致连接无法及时释放 - 该命令输出可能极长，建议管道过滤：
php start.php connections | head -50
真正容易被忽略的是：status 和 connections 都依赖同一个底层机制（Unix socket + 共享内存），一旦 socket 权限错、路径错、版本低或没加 -d，两个命令都会失效 —— 所以排查永远从启动方式和权限开始，而不是怀疑命令本身。
