webman本身不内置任务队列，需依赖插件或外部中间件；推荐redis streams实现发布-拉取模型，支持消费者组、ack重试与位点追踪，配合协程http客户端和webman/crontab插件实现高可靠异步任务分发。
Webman 本身不内置任务队列，得靠插件或自建
Webman 没有像 Laravel Horizon 或 ThinkPHP 的 queue 组件那样开箱即用的任务队列，它的核心定位是高性能 HTTP/WS 服务，任务分发必须显式引入外部能力。直接写 exec('php think queue:work') 或调用同步 shell 命令会阻塞协程，完全违背设计初衷。
真实项目中只有两条路可走：
- 用官方推荐的
webman/console+webman/crontab做轻量级定时触发（适合秒级轮询、日结类低频任务） - 对接独立消息中间件：Redis Streams（推荐）、RabbitMQ 或 Kafka，Webman 只做生产者和回调网关
- 避免在 Webman 进程内启动长时消费进程（如
php start.php start -d启多个 worker 消费），这会导致内存泄漏和 reload 失效
协程环境下 Redis Streams 是最稳的分发通道
用 Redis Streams 实现「发布-拉取」模型，比 Pub/Sub 更可靠：支持消费者组、ACK 重试、游标位点追踪。Webman 发送任务只需一条 $redis->xadd()，客户端用 $redis->xreadgroup() 拉取，天然适配协程。
关键配置注意点：
- Redis 连接必须启用
pconnect，否则每次xadd都新建连接，高并发下很快打满max_connections - 消费者组名要带业务前缀，比如
task:invoice:group1，避免不同服务共用组导致 ACK 冲突 -
XREADGROUP调用必须加BLOCK 5000，否则空轮询吃光 CPU；但别设成BLOCK 0（永久阻塞），会卡死整个协程调度器 - 消息体建议用 JSON，且字段精简，
body字段别塞完整订单对象——序列化/反序列化耗时会拖慢吞吐
AI 类任务分发必须绕过 Guzzle，改用 Swoole 协程 HTTP 客户端
如果你的任务是调用 OpenAI/Kimi/本地 LLM，用 guzzlehttp/guzzle 或 curl_exec 就等于放弃协程。一个请求卡住，整条协程就挂起，100 并发变成 100 串行。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
正确做法是：
- 在
config/app.php中确认'event_loop' => 'swoole'已生效（不是'ev'或'libevent'） - HTTP 请求全部换成
Swoole\Coroutine\Http\Client，并配合go(function () { })启动子协程 - 流式响应（
stream=true）必须用webman-php/openai，它封装了 SSE 解析逻辑；原生 client 需手动按data:行切分，极易漏帧 - 别在单个协程里连续发 10 个 AI 请求——应拆成 10 个独立
go()，每个持独立 client 实例，才能真正并发
定时触发任务不能依赖 system cron，得用 Webman 自带的 crontab 插件
Linux 系统 cron 无法感知 Webman 的常驻内存特性：你改了代码、热更新了，但系统 cron 还在调用旧版本的 php start.php，结果跑的是已卸载的逻辑。
必须用 webman/crontab 插件，在 PHP 进程内调度：
- 安装后在
config/plugin/webman/crontab/app.php里写规则，例如'0 * * * *' => \app\command\DailySettle::class - 所有任务类必须实现
CommandInterface，且方法名固定为handle() - 注意
onWorkerStart阶段才真正加载 crontab，所以数据库/Redis 初始化逻辑必须放在这里，不能放在构造函数里 - 上线前用
php start.php start -d && ps aux | grep crontab确认进程存在，否则说明插件未加载成功
最常被忽略的是：Webman 的定时任务和消息队列消费是两套生命周期。任务触发后生成消息，但消费端可能还没启动；或者消费端重启了，但 Redis Stream 里的 pending list 还在。这类状态不一致必须靠幂等设计+人工巡检补位，框架不会替你兜底。
