websocket私密频道权限控制需在应用层实现：连接时用jwt鉴权并缓存授权频道，推送前实时校验用户对目标频道的访问权限，禁止客户端自行构造频道名，敏感操作需额外角色校验与日志告警。
WebSocket 本身不内置权限控制或频道隔离机制，私密频道和权限校验必须在应用层实现。核心思路是：连接建立后立即鉴权，按用户身份分配可订阅的频道，所有推送前验证目标用户是否具备该频道访问权限。
连接建立时完成身份认证与频道授权
客户端发起 WebSocket 连接时，应在 URL 中携带短期有效的认证凭证（如 JWT），服务端在 upgrade 阶段解析并验证：
- 检查 token 是否未过期、签名有效、且包含用户 ID、角色、可访问频道列表（如
["private:u123", "team:dev"]） - 拒绝非法 token 的连接请求，直接返回 401 状态码并中断握手
- 验证通过后，将用户 ID 与 WebSocket 实例关联，并缓存其授权频道集合（建议用 Map 或 Redis 存储）
服务端维护频道-用户映射关系
私密频道（如 private:user_888、direct:7721-9345）不能全局广播，需精确路由：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 避免使用“发布/订阅”泛播模型；改用显式分发：收到推送指令后，先查该频道对应哪些在线用户，再逐个检查其授权列表中是否包含该频道
- 推荐用内存结构（如
Map<string set>></string>）管理频道活跃连接，配合定时心跳清理离线连接 - 敏感操作（如向
private:admin_logs推送）应额外校验用户角色，而不仅是频道名匹配
消息推送前强制执行细粒度权限校验
每次调用 send() 前必须重验，防止因缓存过期或越权订阅导致数据泄露：
- 例如：管理员向频道
private:order_5566推送更新，服务端需确认接收方用户确实在该订单的viewers白名单中（可查数据库或 Redis 缓存） - 频道名不应直接暴露业务逻辑（如避免
private:delete_user_123），推荐用 UUID 或哈希值标识资源，权限由后端策略引擎判定 - 对高敏频道（如财务、审计类），可增加二次确认钩子，记录日志并触发告警
客户端只订阅已授权频道，禁止自行构造频道名
前端不可信任，所有频道订阅请求必须经服务端审批：
- 客户端发送
{"type":"subscribe","channel":"private:user_999"}后，服务端须再次核验当前连接所属用户是否有权加入该频道 - 服务端返回成功响应后，才将该连接加入频道连接池；否则返回错误并关闭连接
- 前端收到未授权频道的推送时，应主动关闭连接并提示“会话异常”，而非静默丢弃
不复杂但容易忽略：权限判断必须在每次推送前实时发生，不能仅依赖连接建立时的一次性授权。频道命名要抽象，权限决策要中心化，连接状态要及时同步。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
