webman 不内置设备发现协议，无法直接实现 coap+ual 内网自动发现；其角色应为发现结果的消费端或纳管代理网关，通过 http 接收 webmaster 推送的设备列表并缓存至 redis，而非作为 coap 发起者。
Webman 本身不内置设备发现协议，它不能直接实现类似 CoAP + UAL 的内网设备自动发现。真正在做这事的是交换机固件（如 S5700/S6700）和 WebMaster 平台，Webman 只能作为后端服务接收、解析或转发这类发现结果。
为什么 Webman 不适合直接跑 CoAP/UAL 设备发现
CoAP 是一种轻量级 UDP 协议，专为资源受限设备设计；UAL 是华为定义的自治连接抽象层，依赖底层硬件支持与特定报文格式。Webman 基于 Workerman，默认监听 TCP HTTP 端口，不具备原生 CoAP Server 能力，也没有对 CoAP 报文编码/解码、Observe 机制、块传输（Block-Wise）等的支持。
常见误操作是试图用 file_get_contents("coap://...") 或封装 cURL 调 CoAP 接口——这根本不可行，PHP 没有标准 CoAP 客户端扩展，且 UDP 协议栈无法被普通 HTTP 框架直接调度。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Workerman 默认不启用 UDP 协程 Hook，
Swoole\Runtime::enableCoroutine()对 UDP socket 支持有限 - CoAP 需要处理重传、确认、Token 匹配等状态逻辑，不是简单发包收包
- UAL 发现阶段依赖设备主动广播 CoAP 发现请求（如
/.well-known/core），Webman 无能力监听该广播
Webman 在设备发现流程中的合理角色
它适合做「发现结果的消费端」或「纳管代理网关」，而非发现发起者。典型链路是：成员设备 → 主设备（WebMaster）→ Webman 后端 API。
- WebMaster 完成 CoAP 自发现后，把设备列表通过 HTTP POST 推送到 Webman 的
/api/v1/devices/sync接口 - Webman 接收后校验签名、去重、写入 Redis 缓存，并触发 WebSocket 广播给前端拓扑图
- 若需反向查询某设备能力，Webman 调用
Swoole\Coroutine\Http\Client向该设备的 CoAP 网关（如http://192.168.1.100:5683代理）转发请求，而非直连 CoAP - 所有设备元数据（IP、型号、状态）应存于
redis而非 MySQL，避免发现高频写入拖慢主业务
如果硬要在 Webman 上对接 CoAP 设备，必须绕过框架封装
只能退到 Swoole 底层，自行实现 UDP Server + CoAP 解析器，且必须放弃 Webman 的 HTTP 路由和中间件体系。
- 在
app/process/CoapDiscoveryProcess.php中启动独立协程进程，调用Swoole\Coroutine\UDP\Server - 手动解析 CoAP packet header（4 字节）、Token（0–8 字节）、Options（TLV 编码），不依赖任何第三方库
- 响应
2.05 Content时需严格按 RFC 7252 设置 Message ID、Token、Confirmable 标志位 - 该进程无法使用 Webman 的
$request->input()或 Session，所有状态需自行维护在static $devices或共享内存中
这种做法破坏了 Webman 的工程一致性，调试困难，且一旦 CoAP 报文格式升级（如 CoAP over QUIC），整个逻辑需重写。
