Workerman的命令行操作核心是通过php start.php [命令] [选项]管理服务，支持start、stop、restart、reload和status等命令，实现服务的启动、停止、重启、平滑重启与状态查看；平滑重启（reload）可在不中断连接的情况下更新代码，适合生产环境；调试时建议前台运行查看实时日志，结合status命令和日志文件排查端口占用、路径错误、扩展缺失等问题；多进程下命令作用于整个应用，无法直接操作单个Worker，但可通过系统命令kill指定PID实现局部重启，主进程会自动拉起新进程，确保服务稳定。
Workerman的命令行操作，说白了，就是通过执行你的Workerman应用主文件，然后带上一些参数来告诉它该干什么。核心逻辑非常直接：启动、停止、重启、查看状态，这些都是围绕你那个
php your_workerman_script.php
命令展开的。掌握了这些基础，你就能把Workerman服务玩转起来，无论是开发调试还是生产部署，都离不开它。
解决方案
Workerman的命令行操作主要围绕着你的应用入口文件。假设你的Workerman应用入口文件是
start.php
，那么所有的操作都将通过
php start.php [命令] [选项]
的形式进行。
最常用的几个命令包括：
-
启动服务：
php start.php start
这个命令会在前台启动Workerman服务。如果你想让它在后台运行，也就是所谓的守护进程模式，就需要加上
-d
参数：
php start.php start -d
。我个人觉得，调试的时候在前台跑很方便，能直接看到日志输出，一旦确定没问题了，再扔到后台去。
-
停止服务：
php start.php stop
这个会尝试优雅地停止所有Workerman进程。如果遇到僵尸进程或者服务死活停不下来，可以尝试强制停止：
php start.php stop -g
。
-g
参数会发送
SIGKILL
信号，直接杀死进程，但这样可能会导致正在处理的请求中断，所以非必要不推荐。
-
重启服务：
php start.php restart
顾名思义，就是先停止再启动。同样，可以带上
-d
参数让它在后台重启：
php start.php restart -d
。
-
平滑重启：
php start.php reload
这是Workerman一个非常棒的特性。它会在不中断现有连接的情况下，重新加载Worker进程的代码。这对于线上更新代码非常有用，用户几乎无感知。通常，你修改了业务代码后，只需要执行
php start.php reload
，Workerman就会逐步替换旧的Worker进程。
-
查看服务状态：
php start.php status
这个命令会显示Workerman服务当前的运行状态，包括每个Worker的进程ID、内存占用、连接数、请求数等等。这是排查问题和监控服务健康状况的第一手资料。
一个简单的例子： 假设你的
start.php
内容如下：
<?php require_once __DIR__ . '/vendor/autoload.php'; use WorkermanWorker; $http_worker = new Worker("http://0.0.0.0:2345"); $http_worker->onMessage = function($connection, $data) { $connection->send('Hello Workerman!'); }; // 运行所有Worker Worker::runAll();
那么，你就可以这样操作：
- 启动：
php start.php start -d
- 查看状态：
php start.php status
- 修改代码后平滑重启：
php start.php reload
- 停止：
php start.php stop
Workerman服务启动后如何确保其稳定运行并实现平滑重启？
确保Workerman服务稳定运行，并能进行平滑重启，这在生产环境中是至关重要的。我个人的经验是，首先要利用好Workerman自带的守护进程模式和平滑重启机制，这是基础。
启动时务必使用守护进程模式：
php your_workerman_script.php start -d
。这样服务会在后台运行，不会因为你关闭终端而停止。我见过不少新手，直接
php start.php start
，然后终端一关，服务也跟着没了，这就是没理解守护进程的意义。
平滑重启是Workerman的一大亮点，它的核心在于
php your_workerman_script.php reload
。当你执行这个命令时，Workerman会向所有子进程发送一个信号，通知它们在处理完当前请求后退出，然后主进程会启动新的子进程来替代它们。这个过程是渐进的，不会一下子中断所有服务，确保了用户体验。但这里有个小坑，如果你修改了
onWorkerStart
这类在Worker启动时才执行的逻辑，或者一些全局配置，
reload
可能无法完全生效，因为有些代码是在主进程启动时就已经加载的。所以，遇到这种情况，可能还是需要
restart
一下。
另外，日志是服务稳定运行的眼睛。Workerman默认会将日志输出到
Worker::$logFile
指定的文件中，如果没有指定，在守护进程模式下会输出到
/dev/null
或者默认的日志文件。确保你的日志文件可写，并且定期查看日志，可以帮助你发现潜在的问题，比如内存泄漏、异常报错等。我通常会结合
tail -f your_workerman_script.log
来实时监控服务状态，一旦有异常，立马就能看到。
调试Workerman应用时，命令行有哪些实用技巧或常见问题排查方法？
调试Workerman应用，命令行是你的主战场。我发现最实用的技巧就是利用前台启动模式和日志输出。
首先，前台启动：
php your_workerman_script.php start
（不加
-d
）。这样所有的
echo
、
var_dump
以及PHP的错误信息都会直接输出到你的终端，一目了然。当你代码有语法错误、逻辑问题或者想看某个变量的值时，这比去翻日志文件要快得多。我就经常在开发阶段用这种方式，快速定位问题。
其次，善用
status
命令：
php your_workerman_script.php status
。这个命令能告诉你每个Worker进程的PID、内存占用、连接数、请求数等。如果发现某个Worker进程的内存占用异常高，或者连接数一直不下降，那很可能就是有内存泄漏或者连接没有正确关闭。你可以根据PID去进一步排查，比如用
strace -p [PID]
看它在干什么。
日志文件：Workerman的错误日志默认会输出到
Worker::$logFile
指定的文件。如果没指定，在守护进程模式下，Workerman会尝试将标准输出和标准错误重定向到
/dev/null
或默认日志文件。所以，确保你了解日志的去向。我习惯在
Worker::$logFile
里明确指定一个路径，比如
Worker::$logFile = '/var/log/workerman/app.log';
，这样所有的运行日志和错误都能集中管理。当服务出问题时，第一件事就是
tail -f /var/log/workerman/app.log
，看看有没有报错信息。
常见问题排查：
- 端口被占用： 启动时报错“Address already in use”。这通常意味着你尝试监听的端口已经被其他程序占用了。你可以用
netstat -tulnp | grep [端口号]
来查找是哪个进程占用了端口，然后决定是杀死那个进程还是更换Workerman的监听端口。
- 文件路径问题： Workerman应用依赖的类库或文件找不到。检查你的
require_once
路径是否正确，
vendor/autoload.php
是否加载了正确的自动加载文件。
- PHP版本或扩展问题： Workerman对PHP版本和一些扩展（如
event
、
posix
、
pcntl
）有要求。如果报错说某个函数不存在，很可能是PHP缺少了必要的扩展。
php -m
可以查看已安装的扩展。
- 死循环或长时间阻塞： 如果服务启动后，某个Worker进程CPU占用率一直很高，或者不响应任何请求，可能是代码里有死循环或者IO操作长时间阻塞。这时
status
命令可能会显示该Worker的请求数不再增加。在前台模式下，你可能会看到PHP的超时错误。
Workerman命令行操作中，如何处理多进程模式下的特定Worker或服务的管理？
Workerman在多进程模式下，其命令行操作通常是针对整个Workerman应用实例的。也就是说，当你执行
start
、
stop
、
reload
这些命令时，它们会影响到你应用中的所有Worker进程，而不是某个特定的子Worker。
Workerman的设计哲学是，一个Workerman应用通常包含一个或多个
Worker
实例（比如一个HTTP Worker，一个WebSocket Worker），这些实例由一个主进程管理，并派生出多个子进程来处理并发。命令行操作的粒度是这个“Workerman应用”，而不是它内部的某个子Worker进程。
举个例子，如果你定义了
$http_worker
和
$websocket_worker
两个Worker实例，当执行
php start.php reload
时，这两个Worker实例下的所有子进程都会被平滑重启。你无法直接通过Workerman的命令行，单独去重启
$http_worker
下的某个进程，而保留
$websocket_worker
的进程不动。
当然，如果你有多个独立的Workerman应用（比如
app_http.php
和
app_websocket.php
），那么每个应用都有自己独立的命令行接口。你可以分别对它们进行启动、停止和重启操作。这其实是更常见的部署方式，将不同的服务拆分成独立的Workerman应用来管理，这样可以提高服务的独立性和可维护性。
status
命令会显示每个Worker进程的详细信息，包括进程ID（PID）。虽然你不能直接通过Workerman命令行去操作某个PID，但你可以利用这些信息进行系统层面的管理。比如，如果你发现某个特定的Worker进程（通过
status
看到的PID）内存泄漏严重，你可以在系统层面使用
kill [PID]
命令来强制杀死它。Workerman的主进程会检测到子进程的退出，并自动拉起一个新的子进程来替代它，这在一定程度上也能实现“局部重启”，但这不是Workerman命令行提供的直接功能，而是利用了操作系统的进程管理机制。
总的来说，Workerman的命令行设计是简洁而高效的，它专注于对整个应用实例的生命周期管理。对于更细粒度的控制，我们通常会考虑将服务拆分，或者在系统层面结合
ps
、
kill
等命令进行辅助管理。
以上就是Workerman怎么进行命令行操作？Workerman命令行php 操作系统 app websocket 工具 ai workerman 常见问题 内存占用 php echo NULL 循环 接口 Event var 并发 http websocket Workerman