Workerman开发核心是Worker实例生命周期管理，需先引入autoload再实例化Worker；必须调用Worker::runAll()启动事件循环，回调中通过ConnectionInterface操作连接，调试需配置日志或发送响应。
Workerman 的开发流程不是“先写类再启动服务”那种传统框架套路，而是围绕 Worker 实例的生命周期组织的——你写的不是“应用”，而是一组可独立运行、可复用的网络服务进程。
怎么创建一个最简 Worker 实例
核心就两步：引入 autoload + 实例化 Worker。不需要继承、不需要注解、不依赖容器。
常见错误现象：Class 'Workerman\Worker' not found，本质是没正确加载 autoload（Composer 安装后必须用 vendor/autoload.php）。
实操建议：
- 确保已通过
composer require workerman/workerman安装 - 入口文件第一行必须是
require __DIR__ . '/vendor/autoload.php'; - 直接 new
Worker，参数是监听地址，如'tcp://0.0.0.0:2345'或'http://0.0.0.0:8080' - 不要试图在构造函数里做耗时初始化——
Worker实例在主进程创建，但真正运行在子进程里
示例片段：
require __DIR__ . '/vendor/autoload.php';
use Workerman\Worker;
$worker = new Worker('tcp://0.0.0.0:2345');
$worker->onMessage = function($connection, $data) {
$connection->send("Hello: $data");
};
为什么必须调用 Worker::runAll() 而不是直接 start
runAll() 是 Workerman 的事件循环入口，它会 fork 子进程、初始化 Reactor/Worker 进程模型、接管信号处理——不是“启动服务”，而是“交出控制权”。没有它，代码执行完就退出。
容易踩的坑：
- 把
runAll()写在条件判断或函数里，导致根本没执行 - 误以为
$worker->start()是启动方法（它只是注册到全局管理器，不触发运行） - 在 CLI 之外环境（如 Web Server）中调用
runAll()，会报STDIN is not a tty或直接卡死
使用场景：只应在常驻 CLI 脚本末尾调用一次，且必须是最后一行有效代码。
onMessage / onConnect 回调里的 $connection 是什么
它不是 socket resource，也不是 Stream，而是 Workerman 封装的 ConnectionInterface 实现类（如 TcpConnection）。所有 I/O 操作都走它，屏蔽底层差异。
关键点：
-
$connection->send()是异步写入缓冲区，不阻塞；多次调用会追加，不会覆盖 -
$connection->close()后不能再 send，但不会立即断开——Workerman 会等缓冲区清空后再关闭连接 - HTTP 场景下，
$connection是HttpConnection，有$connection->header()和$connection->end()等专用方法 - 别在回调里用
sleep()或阻塞 IO（比如 file_get_contents），会拖垮整个进程
调试时为什么 var_dump 不显示、日志没输出
Workerman 默认关闭了标准输出重定向，且子进程不继承父进程的 stdout/stderr。直接 echo 或 var_dump 会丢弃，看不到任何东西。
实操建议：
- 用
Worker::$stdoutFile = __DIR__ . '/workerman.log';统一捕获所有输出 - 生产环境务必关掉
Worker::$daemonize = true，否则日志全进黑洞 - 调试 HTTP 服务时，优先用
$connection->send("debug: ...")把信息发回客户端，比查日志快得多 - 想看进程状态？用
php your_file.php status，不是ps aux | grep php
性能影响：频繁写大日志会拖慢单个 Worker 进程，尤其在高并发下。日志应精简，必要时按连接 ID 打标。
复杂点在于：Workerman 的“进程模型”和“回调驱动”是强耦合的，一旦理解偏了（比如当成普通 PHP 脚本去写逻辑），后面所有问题都会变成“为什么没反应”“为什么连不上”“为什么内存涨得快”。它不隐藏细节，也不替你决策——你得亲手管好每个连接的生命周期、每个子进程的资源释放、每次 fork 后的上下文隔离。
