WebSocket协议本身不支持消息优先级，必须在应用层用多队列+权重调度实现；uWebSockets.js和Swoole等高性能方案效果最稳，SocketRocket需依赖GCD队列优先级，sockjs-client只能靠缓冲延迟微调。
直接结论：WebSocket协议本身不支持消息优先级，必须在应用层用多队列+权重调度实现；uWebSockets.js 和 Swoole 等高性能方案效果最稳，SocketRocket 需依赖 GCD 队列优先级，sockjs-client 只能靠缓冲延迟微调。
uWebSockets.js 中用多队列 + 权重轮询调度
uWebSockets.js 没有
这类原生 API，但它的异步非阻塞特性允许你在应用层安全地维护多个发送队列。关键不是“谁先发”，而是“谁多发”——用权重控制每轮调度中各队列的出队数量。
高优先级队列（
）每次处理 8 条，中优先级（
）4 条，低优先级（
）1 条，这个比例比固定时间片更抗突发流量
不要用
做无差别轮询，而应在每次
成功回调后主动触发下一轮调度，避免堆积未确认消息
权重值建议用整数（如 8:4:1），而非浮点或百分比，避免浮点误差导致某队列长期饥饿
务必加长度限制：
，否则内存泄漏风险极高；超限时应丢弃旧消息或降级到低队列
Swoole 的
实现真实优先出队
PHP 的
是真正按优先级堆排序的结构，比手动轮询更精确。但要注意它默认是“最大优先出队”，且同优先级时顺序不可靠——必须重写
方法补上插入序号。
插入消息时必须带
字段：
返回值必须是整数：同优先级时用
实现 FIFO
不要在
回调里直接
所有连接，应先入队，再由定时器统一消费，否则并发写 socket 易触发
每轮消费限制
，防止单次推送卡住整个 worker 进程
SocketRocket 用 GCD 队列优先级模拟权重
Objective-C 的 SocketRocket 底层基于
，不能改协议，但可以利用 GCD 的队列优先级做粗粒度分流。注意：这不是真正的消息级优先级，而是“哪类消息的发送任务先被 CPU 调度”。
WebSocket简单聊天室
WebSocket简单聊天室
下载
创建两个串行队列：
（
）和
（默认）
紧急消息走
，普通消息走
别把所有消息都塞进
队列——iOS 系统会降级甚至冻结它，反而导致整体延迟升高
无法控制 WebSocket 帧发送顺序，仅影响本地任务入队时机；网络层仍可能因 TCP 拥塞控制打乱顺序
sockjs-client 的缓冲区只能做“软优先级”
的
本质是 FIFO 缓冲，没有优先级字段。所谓“优先”，只能靠延迟调度机制间接实现：让关键消息早入队、普通消息晚入队，抢在下一轮
前被消费。
可在业务层封装
，内部先清空
再
，确保它排在最前
避免修改
原文件，用继承方式扩展：
25ms 延迟是硬编码，不要盲目调小——低于 10ms 容易触发浏览器节流，反而增加平均延迟
该方案只适用于降级兜底场景，比如 WebSocket 断连后切到 XHR 传输时保关键指令
真正难的不是代码怎么写，而是业务权重怎么定：支付确认和服务器告警都是 P0，但前者必须端到端 priority: 3 就完事。
send(priority)p0p1p2setIntervalws.send()queues.p0.length <= 50SplPriorityQueueSplPriorityQueuecompare()seq$queue->insert(['payload' => $data, 'priority' => 3, 'seq' => $seq++], 3)compare()$a['seq'] < $b['seq'] ? 1 : -1on('message')pushERR_CONNECTION_REFUSED$limit = 30dispatch_queue_thighPriorityQueueDISPATCH_QUEUE_PRIORITY_HIGHnormalQueuedispatch_async(highPriorityQueue, ^{ [self.ws send:data]; })normalQueueHIGHsockjs-clientBufferedSendersendSchedule()sendUrgent()sendBufferpushbuffered-sender.jsclass UrgentBufferedSender extends BufferedSender