WebSocket连接需用ws://或wss://协议，监听open/error/close事件，生产环境必须用wss，反向代理须透传Upgrade头并设HTTP/1.1。
直接用 WebSocket 构造函数就能建立连接，但必须确保服务器端已启用 WebSocket 协议并监听对应路径，否则会卡在连接阶段或报 Failed to construct 'WebSocket': The URL's scheme must be either 'ws' or 'wss' 这类错误。
WebSocket 构造函数的 URL 格式必须正确
浏览器只接受 ws://（非加密）或 wss://（TLS 加密）开头的地址，不能用 http:// 或 https:// 替代。
-
new WebSocket("ws://localhost:8080/chat")—— 本地开发常见，但仅限测试；生产环境必须用wss -
new WebSocket("wss://api.example.com/ws")—— 生产必需，否则 Chrome/Firefox 会在控制台警告并可能拦截连接 - 带查询参数是允许的：
new WebSocket("wss://example.com/ws?token=abc123")，但注意 URL 编码，避免&或空格导致解析失败 - 不能省略端口：如果后端跑在非标准端口（如
8080），ws://example.com:8080中的:8080不可省略；wss默认走 443，ws默认走 80，但显式写出更稳妥
连接过程必须监听 open/error/close 事件
WebSocket 是异步连接，不会阻塞 JS 执行，也不抛出同步异常。不监听 onopen 就贸然调用 send()，大概率触发 InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state。
- 务必在
onopen回调里发首条消息，例如：const ws = new WebSocket("wss://example.com/ws");<br>ws.onopen = () => {<br> ws.send(JSON.stringify({ type: "auth", token: "xyz" }));<br>}; -
onerror不代表连接失败，它常在onopen之前被触发多次（比如 DNS 解析失败、SSL 握手失败），真正判断失败应结合onclose的event.code和event.reason -
onclose的code值有含义：1000 是正常关闭，1006 是连接异常中断（常见于网络闪断或代理中断），4000+ 通常是服务端自定义错误码
MessageWebSocket / StreamWebSocket 是 Windows Runtime API，不是 HTML 标准
如果你在写通用网页（非 UWP/Windows 应用），MessageWebSocket 和 StreamWebSocket 完全不可用——它们属于 Windows.Networking.Sockets 命名空间，仅限 Windows 8.x/10 UWP 应用中通过 JavaScript 调用，且需声明 internetClient 功能权限。
立即学习“前端免费学习笔记（深入）”；
- 网页脚本里写
new MessageWebSocket()会直接报ReferenceError: MessageWebSocket is not defined - UWP 应用中才可用，且必须用
var ws = new Windows.Networking.Sockets.MessageWebSocket();，构造方式、事件名（如onmessagereceived）、数据读取方式（DataReader）都和标准WebSocket不同 - 标准 HTML 页面唯一合法的 API 就是全局
WebSocket构造函数，别被文档标题误导
最容易被忽略的是：WebSocket 连接成功后，服务端是否真的完成了协议升级（Upgrade: websocket）。很多“连不上”的问题其实出在反向代理（Nginx、Cloudflare）没透传 Connection 和 Upgrade 头，或者没设置 proxy_http_version 1.1。这时候浏览器控制台只显示 pending，没有明确错误，得抓包看 HTTP 101 响应是否存在。
