Namespace和Room是两层隔离机制：Namespace为服务端预设逻辑分组，需显式声明；Room为运行时动态房间，须手动join/leave。混用易致广播错乱、内存泄漏或权限失控。
Namespace 和 Room 不是“多频道”的简单叠加，而是两层隔离机制：Namespace 是服务端逻辑分组，Room 是运行时动态房间；混用或错用会导致事件广播错乱、内存泄漏或权限失控。
Namespace 必须在服务端显式定义，客户端不能随意创建
Socket.io 的 Namespace 是服务端预设的通信域，客户端只能连接已声明的 Namespace。未定义的路径（如 /chat2）会直接返回 404，不会自动创建。
- 服务端需用
io.of('/chat')或io.of('/admin')显式声明，否则客户端io('/chat2')连接失败 - 每个 Namespace 拥有独立的中间件、事件监听器和
sockets集合，不共享use()或on('connection') - 避免用用户输入动态拼接 Namespace 名（如
io.of('/' + userId)），极易引发内存泄漏——Socket.io 不会自动清理未引用的 Namespace
Room 是运行时绑定的逻辑分组，必须手动 join/leave
Room 不是自动创建的实体，它只在第一个 socket 调用 join() 时生成，且生命周期完全依赖 socket 连接状态；断连后若未显式 leave()，可能残留空 Room。
-
socket.join('room-a')是单向绑定，仅当前 socket 加入；io.to('room-a').emit()才能精准广播 - 不要在
connection回调里无条件join()用户专属 Room（如socket.join(socket.id)），这会让每个连接都占一个 Room，Room 列表膨胀不可控 - 敏感操作（如管理员踢人）应使用
socket.leave('target-room')+io.in('target-room').emit('user-left')组合，避免只发事件却不解除绑定
Namespace + Room 混合隔离时，广播范围优先级固定
广播链路为：Namespace → Room → Socket。三者嵌套时，作用域逐级收窄，但错误写法会让上层失效。
-
io.emit()发送到所有 Namespace 下所有 socket，绕过所有隔离 —— 生产环境禁用 -
io.of('/chat').emit()只发给/chat下所有 socket，无视 Room -
io.of('/chat').to('lobby').emit()才是正确写法：限定 Namespace 后再进 Room，漏掉.of('/chat')就会误发到其他 Namespace 的同名 Room - 调试时可用
io.of('/chat').adapter.rooms查看当前活跃 Room 列表（注意：Adapter 实现不同，Keys 返回格式可能含Map或普通对象）
真正难处理的是跨 Namespace 权限同步问题：比如用户在 /admin 被禁言，如何实时撤回其在 /chat 的发言权限？这无法靠 Room 或 Namespace 自动联动，得靠外部状态存储（如 Redis）+ 主动通知机制，而不是寄希望于 Socket.io 内置功能。
