能，WebSocket URL支持路径参数（如/ws/{user_id}），但需后端框架配合解析，如Spring Boot的@ServerEndpoint与@PathParam、uWebSockets的getParameter、FastAPI的路径注入等；原生ws库等需手动解析。
WebSocket连接URL里能用路径参数吗？能，但要看后端框架是否支持
路径参数（如 /ws/{user_id}/{room_id}）在 WebSocket URL 中是合法的，HTTP 升级请求本身不禁止它，但能否被后端正确解析，完全取决于服务端实现。比如 Spring Boot 的 @ServerEndpoint("/ws/{uid}") 支持 @PathParam 提取；而原生 Java EE 或某些轻量库（如 Jetty 的 WebSocketServlet）默认不解析路径变量，需手动从 session.getRequestURI() 中截取和正则匹配。
常见错误现象：@PathParam("uid") 注入始终为 null，或抛出 IllegalArgumentException —— 这往往是因为你用了不支持该注解的容器，或没配对使用 @ServerEndpoint 而非普通 Servlet。
- Spring Boot +
spring-boot-starter-websocket：直接支持@ServerEndpoint("/chat/{roomId}")和@OnOpen中的@PathParam - uWebSockets（C++）：通过
req->getParameter("first")读取/:first/static/:second形式路由 - FastAPI：用
@app.websocket("/items/{item_id}/ws")，参数自动注入为函数形参 - 原生 Node.js（ws 库）：不解析路径参数，需自己
url.parse(session.upgradeReq.url).pathname再split("/")
query string 参数怎么取？别只依赖 session.getQueryString()
session.getQueryString() 在部分容器（如 Tomcat + JSR-356 实现）中返回 null，因为升级请求的 query string 可能未被完整保留到 Session 对象。更可靠的方式是访问原始 HTTP 请求对象：
- Spring Boot：
@OnOpen方法中用session.getBasicRemote().getSendHandler()不行，得靠HttpServletRequest—— 需配合HandshakeInterceptor将参数提前存入HttpSession或WebSocketSession属性 - Java EE：
session.getUpgradeRequest().getHttpServletRequest().getQueryString() - Node.js（ws）：
ws.on('connection', (socket, req) => { const query = new URLSearchParams(new URL(req.url, 'http://f').search); })
注意：?token=abc123 这类敏感参数会出现在反向代理日志、CDN 缓存键、浏览器历史中，违反 OWASP ASVS 2.1.3。生产环境应改用 Authorization 请求头或子协议协商机制。
为什么推荐用 Sec-WebSocket-Protocol 传初始化参数？
子协议（Sec-WebSocket-Protocol）是在 HTTP Upgrade 头中传递的，不会进入 URL，天然规避 query 泄露风险。服务端可在 onUpgrade 钩子中校验并提取结构化信息，例如：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
new WebSocket("wss://api.example.com/ws", ["auth-v2;uid=123;perm=read", "ctx-2024"])
服务端解析时只需按分号分割、校验签名与过期时间，再绑定会话上下文。这种方式还带来两个隐性好处：
- 协议层强制约束：非法子协议组合（如含未注册字段）可被网关或中间件直接拦截
- 状态机清晰：避免“连接已建、参数未达”的竞态——子协议是握手阶段就协商完成的，比后续
send()消息更早到达 - 兼容性注意：Chrome/Firefox 支持多子协议列表，但某些旧版 iOS WebKit 只认第一个，建议主协议放前面
连接建立后 send() 发参数，该怎么设计消息格式？
不要裸发 socket.send(JSON.stringify({ user_id: "123", action: "join" }))。缺乏类型标识和版本控制，会导致后端无法区分认证消息、心跳、业务指令，也难做灰度升级。
建议定义最小可行消息结构：
{"v": "1.0", "t": "AUTH_INIT", "i": "nonce-abc123", "d": {"uid": "123", "sig": "hmac-sha256..."}}
-
v：协议版本，便于服务端按版本路由处理器 -
t：消息类型，必须枚举（如AUTH_INIT、HEARTBEAT、DATA_PUSH），不能靠d字段内容判断 -
i：客户端生成的唯一序列号，用于幂等和重传追踪 -
d：实际载荷，敏感字段（如 token）应在服务端校验前先解密或验签
真正容易被忽略的是：WebSocket 帧大小限制（默认多数为 128KB）。如果 d 里塞了大对象（如 base64 图片），会触发 close(1009)。务必在发送前检查 JSON.stringify(payload).length，超限时主动分片或拒绝。
