Webman本身没有内置异步任务队列系统，config/process.php配置的process仅为常驻子进程，需手动实现通信协议、超时控制、错误兜底与任务反馈，官方推荐使用redis-queue插件实现可靠异步任务。
Webman 的 process 不是异步任务队列，只是常驻子进程
直接说结论：Webman 本身没有内置的异步任务队列系统。config/process.php 里配的 process 是独立 PHP 子进程，不带任务分发、序列化、重试、回调通知这些能力。很多人以为写了 onMessage 就能像 Swoole 的 $server->task() 那样发完就等结果，其实不是——你得自己搭通信协议、自己处理超时、自己写日志、自己兜底崩溃。
- 它默认不监听任何端口，除非你显式加
listen => 'text://0.0.0.0:12345' -
onMessage收到的是原始字符串，必须手动json_decode()，没反序列化逻辑 - 进程挂了不会自动重启，得手动加
'restart_on_fail' => true并配健康检查 - 没内置失败队列，异常没捕获，整个进程就静默退出，
ps aux | grep redis-queue看不到它了
真要跑异步任务，优先用 Redis 队列插件
Webman 官方推荐且最轻量落地的方案是 plugin/webman/redis-queue。它基于 BLPOP 实现消费者拉取，和 Laravel Horizon 或 ThinkPHP 的队列思路一致，适合导出报表、发邮件、同步第三方数据这类场景。
- 确保插件已启用：
composer require webman/redis-queue，然后在config/plugin/webman/redis-queue/process.php中设'count' => 2（别一上来就设 16） - 消费者逻辑写在
app/queue/Handler.php::handle()，所有外部调用必须带超时：Guzzle 要'timeout' => 3.0，PDO 要设PDO::ATTR_TIMEOUT，Redis 操作要传'timeout' => 1.0 - 加耗时监控：在
handle()开头记microtime(true)，结尾算差值，超过 3000ms 就记日志并告警 - 别用
file_get_contents()或裸curl_exec()，它们卡住整个消费者进程，后面消息全堵在 BLPOP 队列头
Redis 队列积压时，先查三件事
积压不是“等它慢慢消化”，而是信号：消费者可能死了、单条任务卡住了、或者 Redis 连接池被打爆了。必须立刻动手，不能只调 count。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 执行
ps aux | grep redis-queue，确认有活跃进程且TIME列在增长；如果全是defunct或 CPU 为 0.0，说明已僵死，先php webman stop再php webman start -d - 进 Redis 执行
llen webman:queue:default，隔 10 秒再查，值没降？说明没消费或极慢；同时看storage/logs/redis-queue.log里有没有Exception或timeout - 查 Redis 连接上限：
redis-cli config get maxclients，生产建议 ≥ 500；再看 Webman 的config/redis.php里'pool' => ['max_connections' => 20]是否够用（比如count => 4，这里至少设 10）
process + TCP 通信不是银弹，慎用于核心业务
如果你硬要用 process 做任务通道（比如需要实时返回结果），就得自己实现完整协议层。这不是配置问题，是工程量问题。
- 约定请求结构：
{"cmd": "gen_pdf", "user_id": 123, "timeout": 15}，并在onMessage开头就调set_time_limit($data['timeout'] ?? 10) - 所有 I/O 必须设超时：HTTP 用 Guzzle 带
'connect_timeout' => 1.5，DB 查询走框架连接池，Redis 调用传timeout参数 - 执行完必须主动
$connection->send(json_encode(['status' => 'success', 'task_id' => $id]))，不能只echo；异常必须error_log()记到文件，否则进程崩溃无声无息 - 别指望它自动关联用户会话或做任务状态追踪——这些都要你自己存 Redis、打标记、轮询查
实际跑起来你会发现，真正难的不是“怎么发任务”，而是“怎么保证每条都稳稳落地”。哪怕一个 file_get_contents() 没加超时，就能让整个消费者停摆一分钟，而这分钟里积压的消息，没人帮你重试、没人告诉你卡在哪。
