能执行 php start.php status 并返回有效表格，说明 workerman 已成功运行；它通过连接 unix socket 读取共享内存统计信息，比 ps 更可靠，但依赖 -d 模式、正确 pid 文件路径及 socket 权限。
能执行 php start.php status 并返回有效表格，就说明 Workerman 已运行成功；反之，报 “no pid file” 或连不上 socket，基本等于没起来。
status 命令为什么能判断是否成功运行
它不依赖进程“看起来在跑”，而是真实连接主进程的 Unix socket（默认 /tmp/workerman.status）读取共享内存里的统计信息。只要主进程活着、socket 文件存在且权限可读，命令就能返回结果 —— 这比 ps aux | grep workerman 可靠得多，因为后者可能看到僵尸进程或残留 pid。
- 如果服务根本没启动，
status会报错：No pid file或Can not connect to master process - 如果启动时没加
-d（守护进程模式），status会失败：Workerman 默认只在 daemon 模式下创建管理 socket - 如果用 root 启动但普通用户执行
status，大概率因 socket 权限拒绝访问 → 检查/tmp/workerman.*.status的属主和 644 权限
执行 status 前必须确认的三件事
很多“查不到状态”的问题，其实卡在这几步：
- 确保是用
php start.php start -d启动的，不是start（无-d） - 检查
start.php里是否设置了Worker::$pidFile，如果改过路径，status会去错地方找 pid 文件 - 确认
/tmp/workerman.*.status*文件存在且未被清理（比如重启后旧文件残留，会导致新进程无法绑定 socket）
status 输出里哪些字段说明“真的在干活”
别只看有没有表格，盯住这三项变化：
-
connections> 0 且随客户端接入有波动 → 连接层通了 -
total_request在缓慢增长（哪怕每秒 1–2 次）→ 业务逻辑正在被触发 -
mem_usage稳定在几 MB（非 0 或飙升到几百 MB）→ 内存没泄漏也没卡死 - 如果某 worker 的
connections长期为 0 且total_request不动，大概率是它的onMessage回调里抛了未捕获异常，被 Workerman 静默吞掉后不再收新请求
connections 命令不是 status 的替代品，而是补充
php start.php connections 只在 Workerman ≥ 3.5.0 且 TCP/UDP Worker 中生效（HTTP/WebSocket 默认不启用连接级统计）；它输出的是每条连接的原始元数据，不是“是否运行成功”的判断依据，而是用来排查连接泄漏、客户端假死、onClose 卡顿等问题。
- 大量连接
send_queue_size > 0且last_send_time长时间没更新 → 客户端已断开但服务端没感知 - 输出里出现一堆
close_wait→ 很可能是onClose里做了同步 HTTP 请求或日志写入，阻塞了连接释放 - 线上慎用：高峰期执行可能短暂阻塞主进程，建议先
head -50截取前 50 行看趋势
真正容易被忽略的点是：status 能返回结果 ≠ 业务逻辑正常。它只证明主进程和通信通道 OK，而 total_request 不增长、connections 不变化，往往意味着你的回调里有静默失败 —— 这时候得翻 Worker::$logFile，而不是反复敲 status。
