当前位置：首页 > news >正文

Python WebSocket 实战：从零构建轻量级实时聊天应用

news 2026/5/9 4:09:43

1. 项目概述：一个轻量级聊天应用的诞生

最近在GitHub上看到一个挺有意思的项目，叫pymike00/tinychat。光看名字就能猜个大概——这应该是一个用Python实现的、主打轻量化的聊天应用。作为一个在后台开发和网络编程领域摸爬滚打了十多年的老码农，我对这类“麻雀虽小，五脏俱全”的项目总是特别有好感。它们往往不是为了解决什么宏大的商业问题，而是开发者为了解决一个具体的小痛点，或者纯粹为了技术探索和乐趣而诞生的。tinychat给我的第一印象就是如此：它可能没有Slack、Discord那样丰富的功能，也没有微信、QQ那样庞大的生态，但它提供了一个干净、直接的起点，让你能快速理解一个实时聊天应用的核心骨架是如何搭建起来的。

这个项目非常适合几类朋友：一是正在学习Python网络编程和Web开发的同学，想找一个有完整流程、代码量又不至于吓人的实战项目来练手；二是需要快速搭建一个内部团队沟通工具，或者为某个小型活动（比如线上游戏、小型研讨会）提供临时聊天室的后端开发者；三是对WebSocket、异步编程感兴趣，想看看一个最小可行产品（MVP）如何落地的技术爱好者。通过拆解tinychat，你不仅能学会如何让消息在浏览器和服务器之间实时“飞”起来，更能理解一个看似简单的应用背后，关于连接管理、状态同步、异常处理等一系列工程细节的思考。接下来，我就带你一起，从设计思路到代码实现，把这个小项目里里外外摸个透。

2. 核心架构与设计思路拆解

2.1 技术栈选型：为什么是Python + WebSocket？

tinychat的核心技术栈非常清晰：后端用Python，通信协议用WebSocket，前端大概率是简单的HTML/JavaScript。这个组合是构建现代轻量级实时应用的黄金搭档。

首先说Python。选择Python作为后端语言，首要考虑的是开发效率和生态。对于tinychat这类原型或小型应用，Python的简洁语法和丰富的库能让你快速实现想法。项目很可能使用了像Tornado、Sanic或原生的asyncio+websockets库。这些框架或库都原生支持异步I/O，这对于需要同时维持大量持久连接的聊天服务至关重要。同步模型（如传统的WSGI）下，每个连接都会阻塞一个线程，当用户数上去后，线程切换和内存开销会成为瓶颈。而异步模型下，一个线程（或协程）就能处理成千上万个连接，在I/O密集型（聊天就是典型的I/O密集型，大部分时间在等待网络消息）的场景下，资源利用率极高，性能表现也更好。

其次是WebSocket。这是实现全双工、低延迟实时通信的Web标准协议。相比于古老的“轮询”（Polling）或“长轮询”（Long Polling），WebSocket在建立连接后，客户端和服务器可以随时主动向对方发送数据，没有HTTP那种“请求-响应”的 overhead。对于聊天应用，这意味着用户A发送一条消息，服务器收到后可以立即通过已建立的WebSocket连接推送给在线的用户B、C、D，延迟极低，体验流畅。如果使用HTTP轮询，要么需要客户端频繁地问“有新消息吗？”（浪费带宽和服务器资源），要么让连接挂起等待（长轮询），实现复杂且连接管理麻烦。因此，WebSocket是实时聊天功能的不二之选。

前端部分，为了极致的轻量化和易于部署，tinychat大概率没有引入React、Vue等重型框架，而是采用原生JavaScript配合简单的HTML/CSS。这样做的优点是零依赖，一个HTML文件就能运行，学习成本低，也便于我们聚焦于核心的通信逻辑。前端通过浏览器的WebSocketAPI与后端服务建立连接，并处理连接事件、消息收发和界面更新。

注意：技术选型没有银弹。这个组合适合tinychat的定位，但如果你的应用需要复杂的单页面应用（SPA）体验、状态管理或更高的性能天花板，可能需要考虑更专业的前端框架（如Vue/React）和后端语言（如Go, Node.js）。但对于学习和快速原型，Python + WebSocket的组合足够优秀。

2.2 核心架构设计：单服务器与房间模型

从tinychat的名字和定位来看，它的架构不会太复杂。我推测其核心是一个单服务器、多房间（或单大厅）的广播模型。

连接管理：服务器启动后，会监听一个特定的端口（例如8765）。每个用户通过浏览器访问前端页面，页面中的JavaScript会尝试与这个服务器端口建立WebSocket连接。服务器需要维护一个所有活跃连接的列表或集合。在Python中，这通常是一个全局的列表（list）或更高效的集合（set），里面存放着每个连接对象（比如websockets.WebSocketServerProtocol实例）。当新连接建立时，将其加入集合；当连接断开（用户关闭页面或网络异常）时，将其从集合中移除。这是最基础也是最重要的一步，漏掉清理会导致内存泄漏。

消息路由与广播：这是聊天应用的核心逻辑。当服务器从某个连接（代表用户A）收到一条消息时，它需要将这条消息“广播”给其他在线的连接。最简单的实现就是遍历当前维护的所有连接集合（除了发送者自己），然后调用每个连接的send()方法。这就是所谓的“大厅”或“全局广播”模式，所有在线用户都能看到彼此的消息。

房间/频道模型：稍微复杂一点，也是更实用的模型，是引入“房间”（Room）或“频道”（Channel）的概念。用户可以选择加入某个特定的房间（比如“技术交流”、“闲聊区”）。服务器需要维护一个从房间名到连接集合的映射（例如，用字典dict，键是房间名，值是该房间内的连接集合）。当用户发送消息时，需要指明目标房间，服务器只将该消息广播给同一房间内的其他连接。tinychat很可能实现了这个模型，因为它更贴近真实的聊天场景，也能有效隔离不同话题的讨论。

状态与协议：客户端和服务器之间需要约定一个简单的通信协议。消息通常以JSON格式传输，因为其结构清晰、易于解析。一条消息的JSON结构可能包含几个字段：

{ "type": "message", // 消息类型，如“message”、“join”、“leave” "room": "general", // 房间名 "user": "Alice", // 发送者用户名 "content": "大家好！" // 消息内容 }

服务器根据type字段来决定如何处理这条消息：如果是join，就将该连接加入到room字段指定的房间集合中；如果是message，就将content广播给同房间的其他用户；如果是leave，则从房间集合中移除该连接。

这种设计清晰地将业务逻辑（加入/离开房间、发送消息）与网络传输解耦，使得代码易于理解和扩展。

3. 核心模块与代码实现深度解析

3.1 后端服务器核心逻辑实现

我们以使用Python标准库asyncio和第三方库websockets为例，来深入剖析后端服务器的实现细节。首先，你需要安装websockets库：pip install websockets。

服务器启动与事件循环：服务器的入口点是一个异步函数，它绑定到特定主机和端口，并开始监听连接。

import asyncio import websockets import json # 全局数据结构，用于管理房间和连接 # 格式：{“room_name”: set([ws_connection1, ws_connection2, ...])} rooms = {} async def chat_server(websocket, path): """ 每个WebSocket连接建立后，都会创建一个此协程的实例来处理。 :param websocket: 当前的WebSocket连接对象 :param path: 客户端连接的路径（在URI中），可用于区分不同功能 """ # 这里path可以用于提取房间名，例如连接 ws://localhost:8765/room1 # 那么 path 就是 "/room1" room_name = path.strip("/") or "lobby" # 默认房间名为“lobby” user_name = "Anonymous" # 初始匿名，实际应由客户端首次消息提供 # 将当前连接加入到对应的房间 if room_name not in rooms: rooms[room_name] = set() rooms[room_name].add(websocket) print(f"[+] {user_name} 加入了房间 {room_name}。当前房间人数：{len(rooms[room_name])}") try: # 主循环：持续监听该连接发来的消息 async for message in websocket: # 1. 解析客户端消息 try: data = json.loads(message) msg_type = data.get("type", "message") user_name = data.get("user", user_name) # 更新用户名 content = data.get("content", "") # 2. 根据消息类型处理 if msg_type == "join": # 处理加入房间（可能切换房间） pass # 简化处理，这里我们假设连接时即确定房间 elif msg_type == "message": # 构建要广播的消息体 broadcast_msg = json.dumps({ "type": "message", "user": user_name, "content": content, "room": room_name }) # 3. 广播给同房间的其他所有连接 # 注意：需要排除发送者自己，避免自己收到自己的消息 tasks = [] for client in rooms[room_name]: if client != websocket and client.open: tasks.append(client.send(broadcast_msg)) # 并发发送，提高效率 if tasks: await asyncio.gather(*tasks, return_exceptions=True) print(f"[{room_name}] {user_name}: {content}") elif msg_type == "leave": # 处理离开房间 break # 跳出循环，进入finally块进行清理 except json.JSONDecodeError: # 处理非JSON格式消息 error_msg = json.dumps({"type": "error", "content": "Invalid message format"}) await websocket.send(error_msg) except websockets.exceptions.ConnectionClosed: # 连接异常关闭（如网络断开、页面关闭） print(f"[-] {user_name} 的连接异常关闭。") finally: # 无论正常离开还是异常，都要执行清理：从房间中移除连接 rooms[room_name].discard(websocket) print(f"[-] {user_name} 离开了房间 {room_name}。剩余人数：{len(rooms[room_name])}") # 如果房间为空，可以考虑删除该房间键值对以节省内存 if not rooms[room_name]: del rooms[room_name] async def main(): # 启动WebSocket服务器，监听所有网络接口（0.0.0.0）的8765端口 async with websockets.serve(chat_server, "0.0.0.0", 8765): print("Tinychat 服务器已启动在 ws://0.0.0.0:8765") # 保持服务器运行，直到被手动停止 await asyncio.Future() if __name__ == "__main__": asyncio.run(main())

关键点解析：

异步事件循环：asyncio.run(main())启动了Python的异步事件循环，这是所有异步操作的基础。
连接处理函数：chat_server是一个异步函数，每个新连接都会独立运行一个它的实例。async for message in websocket:这行代码是关键，它使服务器可以持续、非阻塞地从这个特定连接读取消息。
房间管理：使用全局字典rooms来管理。set集合用于存储连接，因为它提供了O(1)时间复杂度的添加、删除和成员检查，非常适合这个场景。
广播优化：在广播消息时，我们创建了一个任务列表（tasks），然后使用asyncio.gather并发执行所有发送操作。这比用for循环依次await client.send(...)要快得多，因为后者是顺序等待，而gather是并发执行。return_exceptions=True参数确保即使某个发送任务失败（如客户端突然断开），也不会影响其他任务的执行。
异常处理与资源清理：try...except...finally结构确保了无论连接是正常关闭（客户端发送leave）还是异常断开（网络问题），都会执行finally块中的代码，将连接从房间集合中移除，防止内存泄漏。这是服务器稳定性的基石。

实操心得：在管理全局状态（如rooms字典）时，要特别注意多线程/多协程下的并发安全问题。虽然asyncio是单线程的，但在一个协程修改rooms的同时，另一个协程可能正在遍历它（比如广播时），这可能导致RuntimeError: Set changed size during iteration。更安全的做法是使用asyncio.Lock（异步锁）来保护对共享数据的修改，或者使用专门的数据结构如asyncio.Queue。对于tinychat这种小规模应用，由于连接处理协程在修改rooms（添加/删除连接）时，不会同时进行遍历广播（广播发生在该协程内部，且用到了当前房间连接集合的快照），所以风险较低。但在更复杂的场景下，锁是必须的。

3.2 前端客户端实现与交互

前端的目标是提供一个简单的界面，让用户输入用户名、选择房间、发送和接收消息。我们使用原生HTML、CSS和JavaScript来实现。

HTML结构：

<!DOCTYPE html> <html> <head> <title>TinyChat</title> <style> body { font-family: sans-serif; max-width: 800px; margin: 20px auto; } #chat-box { border: 1px solid #ccc; height: 400px; overflow-y: auto; padding: 10px; margin-bottom: 10px; } .message { margin-bottom: 8px; } .message .user { font-weight: bold; color: #007bff; } .message .system { font-style: italic; color: #6c757d; } #input-area { display: flex; } #message-input { flex-grow: 1; padding: 8px; } #send-button { padding: 8px 15px; } #login-area { margin-bottom: 15px; } </style> </head> <body> <h1>🐣 TinyChat</h1> <div id="login-area"> <input type="text" id="username-input" placeholder="请输入用户名" value="游客"> <input type="text" id="room-input" placeholder="请输入房间名" value="lobby"> <button id="connect-button">连接</button> <button id="disconnect-button" disabled>断开</button> </div> <div id="chat-box"></div> <div id="input-area"> <input type="text" id="message-input" placeholder="输入消息..." disabled> <button id="send-button" disabled>发送</button> </div> <script src="tinychat.js"></script> </body> </html>

JavaScript逻辑 (tinychat.js)：这是前端的核心，负责建立WebSocket连接、处理用户交互和更新界面。

let socket = null; let currentRoom = 'lobby'; let currentUser = '游客'; const chatBox = document.getElementById('chat-box'); const messageInput = document.getElementById('message-input'); const sendButton = document.getElementById('send-button'); const connectButton = document.getElementById('connect-button'); const disconnectButton = document.getElementById('disconnect-button'); const usernameInput = document.getElementById('username-input'); const roomInput = document.getElementById('room-input'); // 工具函数：向聊天框添加一条消息 function appendMessage(type, user, content, room = null) { const msgDiv = document.createElement('div'); msgDiv.className = 'message'; let text = ''; if (type === 'system') { msgDiv.classList.add('system'); text = `[系统] ${content}`; } else if (type === 'message') { text = `<span class="user">${user}</span>: ${content}`; if (room && room !== currentRoom) { text += ` (来自房间: ${room})`; // 如果未来支持接收其他房间消息的提示 } } else if (type === 'error') { text = `[错误] ${content}`; } msgDiv.innerHTML = text; chatBox.appendChild(msgDiv); // 自动滚动到底部 chatBox.scrollTop = chatBox.scrollHeight; } // 连接服务器 connectButton.onclick = function() { currentUser = usernameInput.value.trim() || 'Anonymous'; currentRoom = roomInput.value.trim() || 'lobby'; const serverUrl = `ws://${window.location.hostname}:8765/${currentRoom}`; // 假设服务器运行在8765端口 try { socket = new WebSocket(serverUrl); appendMessage('system', null, `正在连接服务器 ${serverUrl}...`); socket.onopen = function(event) { appendMessage('system', null, `已连接到房间 "${currentRoom}"， 用户名: ${currentUser}`); // 启用消息发送区域 messageInput.disabled = false; sendButton.disabled = false; disconnectButton.disabled = false; connectButton.disabled = true; // 可选：发送一个“join”消息通知服务器用户名 socket.send(JSON.stringify({ type: 'join', user: currentUser, room: currentRoom })); }; socket.onmessage = function(event) { try { const data = JSON.parse(event.data); switch(data.type) { case 'message': appendMessage('message', data.user, data.content, data.room); break; case 'system': // 服务器可能发送的系统消息 case 'error': appendMessage(data.type, null, data.content); break; default: console.log('收到未知类型消息:', data); } } catch (e) { console.error('解析消息失败:', e, event.data); appendMessage('error', null, '收到无效消息格式'); } }; socket.onclose = function(event) { appendMessage('system', null, `连接已断开。`); messageInput.disabled = true; sendButton.disabled = true; disconnectButton.disabled = true; connectButton.disabled = false; socket = null; }; socket.onerror = function(error) { console.error('WebSocket错误:', error); appendMessage('error', null, '网络连接出现错误'); }; } catch (error) { appendMessage('error', null, `连接失败: ${error.message}`); } }; // 发送消息 sendButton.onclick = function() { sendMessage(); }; messageInput.addEventListener('keypress', function(e) { if (e.key === 'Enter') { sendMessage(); } }); function sendMessage() { const content = messageInput.value.trim(); if (!content || !socket || socket.readyState !== WebSocket.OPEN) { return; } const message = { type: 'message', user: currentUser, room: currentRoom, content: content }; socket.send(JSON.stringify(message)); // 本地回显（可选，也可以等服务器广播回来） // appendMessage('message', currentUser, content); messageInput.value = ''; // 清空输入框 messageInput.focus(); } // 断开连接 disconnectButton.onclick = function() { if (socket && socket.readyState === WebSocket.OPEN) { socket.send(JSON.stringify({ type: 'leave', user: currentUser })); socket.close(); // 触发 onclose 事件 } };

前端关键点解析：

连接管理：WebSocket对象是核心。通过new WebSocket(url)建立连接，并通过onopen,onmessage,onclose,onerror四个事件回调来处理连接生命周期。
状态同步：前端需要维护当前用户(currentUser)、当前房间(currentRoom)和连接状态（通过socket.readyState判断）。UI控件的启用/禁用状态（如输入框、按钮）需要与连接状态同步，防止在未连接时发送消息。
消息收发：发送消息时，将JavaScript对象通过JSON.stringify()序列化成字符串，再调用socket.send()。接收消息时，在onmessage回调中，用JSON.parse()解析数据，并根据type字段更新UI。
用户体验细节：
- 本地回显：在sendMessage()函数中，可以选择立即将用户自己发送的消息显示在聊天框（本地回显），以提供更快的响应。但更常见的做法是等待服务器广播回这条消息，这样可以确认消息确实已送达服务器并被成功处理。如果做本地回显，需要小心处理，避免在弱网环境下，用户看到自己发送成功，但服务器实际没收到，造成困惑。
- 自动滚动：在appendMessage函数末尾，通过chatBox.scrollTop = chatBox.scrollHeight;实现聊天内容自动滚动到最新消息，这是聊天应用的标配体验。
- Enter键发送：为输入框添加keypress事件监听，当按下Enter键时触发发送，符合用户习惯。

4. 部署、运行与基础优化

4.1 本地运行与测试

要让tinychat跑起来，你需要分别启动后端服务器和提供前端页面。

准备环境：确保你的Python环境已安装websockets库（pip install websockets）。
启动后端：将上面的Python服务器代码保存为server.py，在终端运行：
```
python server.py
```
你会看到输出：Tinychat 服务器已启动在 ws://0.0.0.0:8765。
提供前端：你需要一个HTTP服务器来提供HTML和JS文件。最简单的方法是使用Python内置的HTTP模块。在与server.py和index.html、tinychat.js同目录下，运行：
```
python -m http.server 8080
```
这会在本地的8080端口启动一个简单的静态文件服务器。
访问测试：打开浏览器，访问http://localhost:8080（如果8080端口被占用，命令会提示，你也可以换成其他端口如8000）。在页面中输入用户名和房间名（或使用默认值），点击“连接”。打开多个浏览器窗口或标签页，分别用不同用户名连接同一个房间，就可以互相发送消息了。

注意事项：这里后端WebSocket服务器运行在8765端口，前端HTTP服务器运行在8080端口，这是两个不同的端口。前端JavaScript中连接的是ws://localhost:8765。在生产环境中，通常会将前后端部署在同一个域名下，通过Nginx等反向代理将WebSocket请求（/ws路径）转发到后端应用服务器，以解决跨域问题。本地开发时，如果遇到跨域错误，可以修改后端服务器代码，在创建websockets.serve时添加origins参数（允许的来源），但这只是开发便捷手段，生产环境务必使用反向代理。

4.2 基础性能与扩展考量

当前的tinychat实现是一个功能完整但非常基础的版本。如果用户量稍大，或者对可靠性要求更高，有几个方面需要考虑优化和扩展：

1. 连接状态与心跳机制WebSocket连接可能因为网络不稳定、代理超时、服务器重启等原因意外断开。为了及时发现死连接并进行清理，需要实现心跳机制（Heartbeat）。客户端定期（比如每30秒）向服务器发送一个特定类型的消息（如{"type": "ping"}），服务器收到后回复一个pong。如果服务器在超时时间内（比如60秒）没有收到某个连接的心跳，则认为该连接已失效，主动关闭并清理它。这可以通过在服务器端为每个连接维护一个“最后活跃时间戳”，并启动一个后台定时任务来检查来实现。

2. 消息持久化当前所有消息都是内存中的，服务器重启或用户重连后，历史消息就消失了。对于正式的聊天应用，通常需要将消息保存到数据库（如Redis、MongoDB或PostgreSQL）。当用户加入房间时，服务器可以从数据库拉取最近的N条历史消息推送给用户。发送消息时，除了广播，也要异步写入数据库。这引入了新的复杂度：数据库选型、消息模型设计、分页查询等。

3. 用户认证与授权目前用户只需输入一个用户名即可加入，没有任何认证。在实际场景中，可能需要登录系统。一个简单的方案是使用JWT（JSON Web Token）。用户先通过一个HTTP登录接口获取Token，然后在建立WebSocket连接时，将Token作为查询参数或首部（部分WebSocket库支持）传递给服务器，服务器验证Token的有效性并获取用户身份信息。这能防止任意用户冒充他人，也为后续的权限控制（如禁言、踢人）打下基础。

4. 水平扩展挑战当前的架构是单服务器的。所有连接和房间状态都保存在该服务器的内存中。这意味着：

单点故障：这台服务器挂了，整个服务就不可用。
容量瓶颈：一台机器的连接数、内存和CPU是有限的。要支持更多用户，需要引入多服务器架构。这带来了状态共享的问题：用户A连接到服务器1，用户B连接到服务器2，但他们可能在同一个逻辑房间。服务器1如何将A的消息广播给连接到服务器2的B？解决方案通常有两种：
使用中心化的消息队列/发布订阅系统：如Redis Pub/Sub。每台服务器都订阅一个全局的频道。当服务器1收到用户A的消息时，它不直接广播，而是将消息发布到Redis的对应房间频道。所有服务器（包括服务器1自己）都会收到这个消息，然后各自广播给自己所维护的该房间的连接。这样，状态（房间成员列表）虽然还是分散在各服务器，但消息通过中心枢纽路由了。
使用专门的实时通信基础设施：如使用Socket.IO的适配器（Adapter）机制，或者直接采用像Apache Kafka、NATS这样的消息系统来在服务器集群间同步事件。

对于tinychat这样的学习项目，短期内无需考虑这些。但理解这些挑战和常见的解决思路，对于构建更严肃的实时应用至关重要。

5. 常见问题排查与调试技巧

在实际运行和开发tinychat这类应用时，你肯定会遇到各种各样的问题。下面我整理了一些典型问题及其排查思路，很多都是我自己踩过的坑。

5.1 连接建立失败

症状：前端点击“连接”后，一直显示“正在连接...”，最终超时或报错。
排查步骤：
1. 检查服务器是否运行：在终端运行netstat -an | grep 8765（Linux/macOS）或netstat -ano | findstr :8765（Windows），看8765端口是否处于LISTEN状态。
2. 检查防火墙：确保服务器防火墙（如ufw,firewalld或Windows防火墙）允许对8765端口的入站连接。本地开发时，可以暂时关闭防火墙测试。
3. 检查地址和端口：前端JavaScript中连接的WebSocket URL（ws://localhost:8765）必须和后端服务器监听的地址端口完全一致。如果服务器运行在虚拟机或容器里，localhost可能需要换成具体的IP地址。
4. 查看浏览器控制台：按F12打开开发者工具，切换到“Console”标签页。这里会有详细的WebSocket连接错误信息，如WebSocket connection to 'ws://...' failed:。常见的错误包括跨域问题（CORS）、协议错误（如尝试用http://连接ws://端口）等。
5. 查看服务器日志：服务器启动时和连接建立时的打印信息是重要的调试依据。确保你的服务器代码在关键节点（如启动成功、新连接建立、连接关闭）都有日志输出。

5.2 消息发送或接收不到

症状：连接成功，但发送消息后，自己或其他用户收不到。
排查步骤：
1. 检查服务器广播逻辑：在服务器的广播代码处（for client in rooms[room_name]:循环内）添加日志，打印出发送者、接收者数量和发送的消息内容。确认循环是否执行，以及client.send()是否被调用。
2. 检查客户端onmessage回调：在前端JavaScript的socket.onmessage函数开始处添加console.log('收到原始数据：', event.data);，确认是否收到了服务器发来的数据。如果没收到，问题在服务器端或网络；如果收到了但没显示，问题在前端的消息解析或UI更新逻辑。
3. 检查JSON格式：确保客户端发送和服务器广播的消息都是有效的JSON字符串。在服务器解析客户端消息时，用try...except捕获json.JSONDecodeError；在客户端解析服务器消息时，也用try...catch。格式错误是常见原因。
4. 检查房间匹配：确认发送消息的用户和接收消息的用户是否在同一个房间。在服务器广播时，打印房间名和房间内的连接数。在前端，检查连接时传入的房间名和发送消息时room字段是否一致。

5.3 连接意外断开与重连

症状：聊天过程中，用户突然掉线，聊天界面停滞。
原因与处理：
- 网络波动：移动网络或Wi-Fi不稳定会导致TCP连接断开。WebSocket的onclose事件会被触发。
- 服务器重启或崩溃：同样会断开所有连接。
- 客户端页面导航或刷新：页面跳转会销毁WebSocket对象。
- 浏览器标签页休眠：一些浏览器为了省电，会暂停非活动标签页的JavaScript执行，可能导致心跳超时。

解决方案：实现自动重连。在前端代码中，不要只在用户点击时才连接。在socket.onclose事件处理函数中，可以加入重连逻辑：

socket.onclose = function(event) { appendMessage('system', null, `连接断开，${reconnectDelay/1000}秒后尝试重连...`); messageInput.disabled = true; sendButton.disabled = true; // 设置一个延时，然后尝试重新连接 setTimeout(connectToServer, reconnectDelay); // connectToServer是封装好的连接函数 // 可以指数退避增加重连间隔 reconnectDelay = Math.min(reconnectDelay * 1.5, 30000); // 最大间隔30秒 };

同时，在socket.onerror中也可以触发重连。注意要避免过于频繁的重连，通常采用指数退避策略。

5.4 性能问题与内存泄漏

症状：随着运行时间增长或用户数增多，服务器内存占用持续上升，响应变慢。
排查与解决：
1. 连接泄漏：这是最常见的原因。确保在任何连接关闭（无论是正常close还是异常ConnectionClosed）的情况下，都执行了从rooms字典中移除连接对象的操作。检查你的finally块或异常处理块是否百分百覆盖了所有退出路径。
2. 大消息或消息风暴：如果某个用户发送了非常大的消息（如图片Base64），或者短时间内发送大量消息，可能导致服务器处理线程阻塞或内存激增。可以在服务器端对消息大小进行限制（如if len(message) > 65536: await websocket.close(1009, “Message too large”)），并考虑对发送频率进行限流（Rate Limiting）。
3. 数据结构低效：当单个房间人数非常多时（比如上千人），遍历集合进行广播会成为瓶颈。虽然asyncio.gather是并发发送，但准备广播列表（遍历房间集合）本身是O(N)操作。对于超大规模房间，可能需要更高级的数据结构或分发策略，比如将用户分组。但对于tinychat的定位，这通常不是问题。