sockjs通过协议协商自动选传输方式：先请求/info获取服务端支持的transports列表，再按优先级依次尝试websocket、xhr流、xhr轮询等，全程对业务透明，且自带会话管理、消息确认与自动重连机制。
为什么直接用 window.WebSocket 在 IE9 或 Android 4.3 WebView 里会报错
因为这些环境压根没实现 WebSocket API，window.WebSocket 是 undefined，任何 new WebSocket() 都会抛 ReferenceError。不是连接失败，是语法执行不过去。现代框架（比如 Angular 的 @angular/platform-browser）也默认不带降级逻辑，不会自动 fallback。
SockJS 怎么自动选传输方式：不是“模拟 WebSocket”，而是协议协商
SockJS 客户端发起连接时，并不直接走 ws://，而是先发一个 OPTIONS + GET 到 /my_prefix/info 接口，服务端返回支持的 transports 列表（如 ["websocket", "xhr_streaming", "xhr_polling"]），客户端按顺序尝试——能用 websocket 就用，不行就切到 xhr_streaming（基于 multipart/x-mixed-replace），再不行才用 xhr_polling（即传统轮询）。这个过程对业务代码透明。
- 必须配好服务端的
sockjs-node（Node.js）或对应后端适配器（如 Java 的sockjs-java），不能只引前端库 -
SockJS的 URL 路径需和服务端 prefix 严格一致，比如前端连new SockJS('https://api.example.com/chat')，服务端就得挂载在/chat路由下 - 不要手动改
transports数组顺序，除非你明确知道某代理（如旧版 Squid）会拦截xhr_streaming
轮询替代不是“退化成 setInterval + fetch”，而是用 xhr_polling 保持语义一致
真正兼容的轮询，不是自己写 setInterval(() => fetch('/api/ws-poll'), 3000)，那样要自己处理消息序号、重复投递、连接状态同步等问题。SockJS 的 xhr_polling 模式自带 session ID 维护、消息确认、自动重连和帧边界解析——它把 HTTP 请求包装成类 WebSocket 的事件流，onmessage 回调拿到的就是纯 payload，和原生 WebSocket 无差别。
- 每次 polling 请求带唯一
sid参数，服务端靠它识别会话并推送未读消息 - 响应体是 JSON 格式数组，如
[["msg1"],["msg2"]]，客户端自动拆包触发多次onmessage - 若连续两次 polling 返回空数组，
SockJS会主动发起新连接，避免长等待
容易被忽略的三个部署细节
很多项目本地跑通，一上生产就 fallback 失败，问题往往出在基础设施层：
- Nginx 反向代理必须透传
Upgrade和Connection头给 WebSocket 分支，但对SockJS的xhr_polling分支反而要禁用这些头，否则某些 CDN（如 Cloudflare 免费版）会拒绝非 upgrade 请求 - 服务端
SockJS实例的sockjs_url配置必须指向可公开访问的 CDN 地址（如https://cdn.jsdelivr.net/npm/sockjs-client@1/dist/sockjs.min.js），否则 IE8 等老浏览器无法动态加载 transport 脚本 - 如果用自签名证书或内网域名，
SockJS的 HTTPS 模式会因证书校验失败静默降级到 XHR，但控制台不报错——得看 Network 面板里实际发的是GET /xxx/xxx/xhr还是GET /xxx/xxx/websocket
