webman不适合直接承载智慧养老全场景，应退居为状态聚合层和策略调度层。其瓶颈在于不支持设备长连接复用与视频流代理，需将设备心跳、告警等剥离至独立swoole websocket server，再通过redis pub/sub或unix socket向webman投递事件，专注处理可缓存、无流式响应的api逻辑。
Webman 本身不是为高并发养老平台“开箱即用”的方案，它适合中等规模、需快速迭代的 BFF 层或轻量级服务，但直接承载全场景智慧养老平台（含设备心跳、视频流代理、实时告警、多端消息推送）会暴露瓶颈。关键不在框架选型，而在分层设计是否让 Webman 做它该做的事。
为什么 Webman 不该直接处理设备长连接和视频流
Webman 基于 Swoole 的协程 HTTP 服务器，HttpServer 默认不支持 WebSocket 长连接复用，更不支持 RTMP/HLS 流式转发。强行在 onMessage 里做设备保活 + 心跳解析 + 消息广播，会导致：
- 协程被阻塞（如调用同步数据库或第三方 API），拖垮整个进程
- 内存泄漏常见于未正确关闭
Connection或未 unset 设备上下文对象 -
Swoole\WebSocket\Server和Webman\Http\Server是两套生命周期，混用易触发Fatal error: Uncaught Swoole\Exception: connection is closed
Webman 应该专注哪几类接口
它最适合做「状态聚合层」和「策略调度层」，而非数据通道。典型适用场景包括：
-
/api/v1/elder/report：汇总老人每日活动热力图（数据来自 Redis 时间序列 + MySQL 基础档案） -
/api/v1/caregiver/schedule：排班逻辑编排（调用TaskService::assign()，内部走异步队列） -
/api/v1/alert/rule：告警规则 CRUD（JSON Schema 校验 + 规则引擎 DSL 解析）
这类接口共性是：有明确输入输出、无流式响应、可缓存、能切分事务边界。别让它碰 file_get_contents('rtsp://...') 或 stream_socket_client()。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
如何安全接入设备心跳与告警事件
必须剥离 HTTP 生命周期。推荐方案是：设备端直连独立的 Swoole\WebSocket\Server 实例（非 Webman 内置），再通过 Unix Socket 或 Redis Pub/Sub 向 Webman 进程投递结构化事件。
- 心跳包格式建议统一为 JSON：
{"sn":"E2024001","ts":1753782345,"voltage":3.28,"rssi":-67} - Webman 接收后只做三件事：存入
redis hset elder:status:E2024001、触发规则引擎RuleEngine::evaluate()、写入 Kafka Topiciot-raw备份 - 禁止在
onOpen中执行Db::table('device')->where(...)->update()—— 改用process进程池异步写
性能临界点在哪？什么时候该切走
当出现以下任一情况，说明 Webman 已超载，需拆出专用服务：
- 单机
Webman进程 CPU 持续 > 70%，且swoole_server->stats()显示request_count增速远高于worker_request_count - 设备在线数 > 5000，
websocket:ping平均延迟 > 800ms（用swoole_timer_tick自测） -
php artisan queue:work队列积压超 1000 条，且failed_jobs表每小时增长 > 50
这时候，Webman 就该退回到 API 网关角色，把设备管理、实时通信、AI 分析全部交给专用微服务 —— 它不是不够快，而是不该背这个锅。
