确认 HTML5 原生 WebSocket 实例需同时满足：ws instanceof WebSocket 为 true、ws.url 以 ‘ws’ 开头，且 Chrome Network 面板中协议类型显示为 WS。
WebSocket 连接成功后怎么确认是 HTML5 原生 WebSocket 实例
只要通过 new WebSocket(url) 创建的对象，就是 HTML5 原生 WebSocket —— 它和长轮询、SSE、Socket.IO 封装层有本质区别。关键看构造方式和原型链，而不是行为特征。
判断逻辑很简单：
-
ws instanceof WebSocket必须为true -
typeof ws.send === 'function'且ws.url可读（非私有属性，但现代 浏览器 已暴露） - 检查
ws.constructor.name是否等于"WebSocket"，可排除 Socket.IO 的Socket实例 - 注意：某些 polyfill（如
websocket-polyfill）会覆盖全局WebSocket，此时instanceof仍成立，但底层可能是XMLHttpRequest模拟 —— 这类不属于真正 HTML5 WebSocket
如何区分 WebSocket 和伪 WebSocket（如 Socket.IO、SSE、长轮询）
不能只看是否“实时”，得抓协议层和初始化痕迹：
- 打开 Chrome DevTools → Network → Filter 输入
ws：原生WebSocket显示为WS类型，协议为ws://或wss://；Socket.IO 初始请求是XHR或POST /socket.io/?EIO=……，之后才升级为 WS - SSE 使用
EventSource，Network 中类型为EVENTSOURCE，响应头含Content-Type: text/event-stream - 长轮询没有持久连接，反复出现相同 URL 的
PENDING → 200XHR 请求，且响应体通常是 JSON 数组或空字符串 - 用
ws.protocol可读取子协议（如"chat", "json"），但 Socket.IO 的socket.protocol是undefined或内部字符串
WebSocket 连接建立时的 HTML5 特征响应头识别
服务器对 WebSocket 升级请求的响应，必须包含特定 HTTP 头才能算合规 HTML5 WebSocket 握手：
立即学习 “ 前端免费学习笔记（深入）”；
- 状态码必须是
101 Switching Protocols - 响应头必须含：
Upgrade: websocket、Connection: Upgrade -
Sec-WebSocket-Accept是必有头，值由客户端Sec-WebSocket-Key经固定算法生成，不可伪造 - 若响应中出现
Access-Control-Allow-Origin: *或对应域名，说明服务端支持跨域 —— 这是 前端 能直接new WebSocket(……)的前提之一
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=为什么 ws.readyState 不足以判断是否 HTML5 WebSocket
readyState 只反映连接状态（0–3），所有兼容 WebSocket API 的对象（包括降级 polyfill）都实现了它。真正容易被忽略的是：
-
WebSocket.CLOSED等常量在原生实现中是全局枚举值，polyfill 通常不挂载到WebSocket构造函数上 - 原生
WebSocket对象不可枚举其事件 处理器（如ws.onmessage是 getter/setter），而部分封装库直接暴露为普通属性 - 调用
ws.close(1001, "going away")时，原生实现严格校验 code 范围（1000–4999，且不能是 1004/1005/1006 等保留值）；违规 code 会抛SyntaxError，而封装层往往静默忽略
真要确认，最稳的方式是结合 instanceof WebSocket + ws.url.startsWith('ws') + Network 面板看协议类型 —— 三者缺一不可。
