WebSocket子协议只能在握手阶段协商，连接建立后ws.protocol即固定不可更改，因其属于HTTP升级请求的一部分，仅在101响应中单向确认；运行时切换需重建连接。
WebSocket 连接建立后无法动态切换 Sec-WebSocket-Protocol；子协议只能在握手阶段协商，连接一旦打开，ws.protocol 就固定了，不可更改。
为什么不能在已建立的 WebSocket 连接上换子协议
子协议是 HTTP 升级握手的一部分，由客户端在 Sec-WebSocket-Protocol 请求头中声明、服务端在响应头中单向确认。整个协商过程发生在 TCP 连接建立后的第一个 HTTP 交互中（即 101 Switching Protocols 响应里）。连接升级完成后，协议栈已进入 WebSocket 帧通信模式，不再支持重新协商子协议。
浏览器 API 也完全不提供类似 ws.renegotiateSubprotocol() 的方法 —— ws.protocol 是只读属性，且仅在 onopen 后可读取一次。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 试图在
ws.send()中发送“协议切换指令”属于应用层自定义逻辑，不是标准子协议切换 - 服务端也无法在连接存活时主动修改
Sec-WebSocket-Protocol响应头（它只出现在握手响应中） - 中间代理或负载均衡器通常会缓存或忽略非握手阶段的协议相关头，进一步限制运行时干预
需要“切换”时的实际做法：重建连接
真正可行的方案是关闭当前连接、用新子协议参数新建 WebSocket 实例。这不是缺陷，而是设计使然 —— 子协议代表的是语义层契约（比如 "jsonrpc" vs "binary-v2"），变更意味着数据格式、错误处理、序列化方式都可能不同，必须从连接源头隔离。
- 调用
ws.close()主动断开，避免等待超时或异常中断 - 新建实例时传入新子协议：例如从
new WebSocket("wss://api/", "v1")改为new WebSocket("wss://api/", "v2") - 注意重连逻辑中清空旧
ws引用，防止事件监听器残留（如重复绑定onmessage） - 若需平滑过渡，可在新连接
open后再关闭旧连接，并手动同步未确认消息
多子协议场景下如何让服务端选对协议
客户端传数组 ["myapp-v2", "myapp-v1"] 并不保证服务端一定选第一个。是否匹配取决于服务端实现逻辑，常见行为有：
- 多数 Node.js 库（如
ws、uWebSockets.js）默认取数组中第一个服务端支持的项 - Python
websockets库要求显式实现select_subprotocol回调，否则直接拒绝握手 - 如果服务端返回的
Sec-WebSocket-Protocol值不在客户端列表中，浏览器会静默忽略，ws.protocol保持空字符串 —— 这是最常见的“看似连接成功但子协议没生效”的原因 - 调试时务必在 DevTools Network 面板检查握手响应头，而非只看
ws.readyState === 1
容易被忽略的关键点
子协议名大小写敏感，且必须完全一致才能匹配；"Chat" 和 "chat" 被视为两个不同协议。服务端若做字符串比较未忽略大小写，或客户端拼写错误（如多空格、多余点号），都会导致 ws.protocol === ""。更隐蔽的是某些反向代理（如 Nginx 默认配置）会剥离 Sec-* 类头部，此时即使客户端和服务端逻辑都正确，协商也会静默失败。
