简介：这是一份计算机网络课程设计《局域网聊天程序》的完整设计说明书，面向软件工程、网络工程等专业学生，也适合需要完成P2P通信类课设的初学者参考。文档以C#为编程语言，基于Visual Studio 2010开发环境，围绕基于P2P技术的局域网聊天需求，详细介绍了需求分析、总体设计、详细设计和系统实现编码与运行结果，覆盖用户注册登录、聊天、文件传输、好友管理等核心功能。资源包共1个doc文件，大小161KB，内容以文字说明、层次模型和数据流程图为主，便于直接阅读和二次编辑。该文档已有559人学习下载，在同类课程设计主题中具备一定参考热度。借助这份说明书，读者可快速掌握局域网聊天程序的系统架构、模块划分、Socket编程要点以及关键函数实现思路，也能引用其中的软件层次结构和数据流程描述来完成自己的课程报告。

1. 局域网聊天程序：课设里最容易被追问到卡壳的一个项目

如果你正在为“计算机网络课设 局域网聊天程序”这个题目发愁，先给你一句实话：这个项目的代码量通常不超过 600 行，真正卡人的不是写代码，而是上线顺序和边界处理。大多数同学会在答辩现场被老师问倒，不是因为不会写 socket，而是因为说不清“消息到了服务端之后发生了什么”“两个客户端同时发消息会怎样”“客户端异常退出后服务器怎么知道”。

这篇文章会把一个能演示、能答辩、能扩功能的 C/S 架构聊天程序拆开讲透：消息格式怎么定、广播逻辑怎么写、客户端掉线怎么感知、防火墙和局域网 IP 怎么绕开。你跟着步骤做完，得到的不是一段抄来的代码，而是一套能对着老师讲清楚“为什么这么设计”的完整方案。

我默认你用的是 Python 3.8+ 自带的标准库 socket 和 threading，不做任何第三方依赖。这样在机房、在实验室、在老师的旧笔记本上都能直接跑，不会因为没网装不了包而翻车。

2. 先定通信协议：消息格式决定了你后面所有的代码

很多人写局域网聊天程序，上来就写 socket.send 和 recv，结果跑起来发现消息乱码、收发错位、有时候一条消息变成两条。这多半不是代码写错了，而是你根本没定义消息格式。

2.1 为什么课设不推荐用 P2P 架构

局域网聊天有两种主流架构：P2P（点对点）和 C/S（客户端/服务器）。P2P 看起来更“高级”，两个客户端直接建立 TCP 连接，不经过中心节点。但课设场景下我强烈建议你选 C/S，原因有三条：

第一，NAT 穿透和打洞技术牵扯到 UDP、端口预测、ICMP 等一堆额外概念，答辩时老师一旦追问，你会被带进一个无底洞。第二，C/S 架构下，服务端天然就是消息中转站，在线名单、广播、历史记录这些课设加分项都挂在服务端逻辑上，代码结构干净。第三，也是最重要的——C/S 架构下的调试可以“单向进行”：先把服务端跑通，客户端就是几个 socket 读写操作，定位问题非常快。

C/S 架构的数据流向是：客户端 A 发送消息到服务器，服务器根据消息类型决定是转发给指定客户端还是广播给所有人。这个模式在教科书里叫“应用层消息转发”，在课设答辩里叫“你能说清楚消息的路由路径”。

2.2 消息帧格式：用 JSON 加换行符解决粘包和拆包

TCP 是流式协议，没有消息边界。你 send 了两次，对方可能一次 recv 就收到了两条消息；也可能你 send 了一条很长的消息，对方要分三次 recv 才能读完。这就是经典的粘包/拆包问题。

课设级别最可靠的解法是：用换行符 \n 作为消息边界，每条消息是一个 JSON 对象。发送端在 JSON 序列化后手动加上 \n，接收端按 \n 做 split，每次消费一条完整的 JSON。

我一般这么定义消息帧：

{"type": "chat", "sender": "张三", "content": "你好"} {"type": "login", "sender": "张三", "content": ""} {"type": "logout", "sender": "张三", "content": ""} {"type": "private", "sender": "张三", "target": "李四", "content": "悄悄话"}

四个字段的含义分别是：

为什么选 JSON？理由很实际：它是课设答辩时最容易解释的序列化格式，老师一眼就能看懂每个字段的作用，而且 Python 的 json 模块可以处理 Unicode 中文，不用你手动处理编码。如果你用自定义分隔符比如 \x01，虽然省流量，但答辩时要多解释两层设计意图，性价比不划算。

接收端的处理代码长这样：

def recv_message(conn): data = conn.recv(4096).decode('utf-8') if not data: return None # 按换行符切割，可能包含多条消息 lines = data.split('\n') while lines: line = lines.pop(0).strip() if not line: continue # 如果一条消息没结束，需要缓存拼接 return json.loads(line)

这里有一个关键点很多人会漏掉：recv 可能只收到了半条 JSON。完整代码里需要加一个缓冲区，把不完整的数据暂存，等下一次 recv 时拼接。这部分逻辑我在避坑章节会细讲。

2.3 端口和地址绑定：为什么选 12345 而不是 80

服务端监听地址要填 0.0.0.0 而不是 127.0.0.1。前者表示监听本机所有网卡接口，局域网里其他机器才能连接进来。后者只允许本机访问，你在实验室里两台电脑联调时就会连接失败。

端口选择有个现实约束：不要选 0-1023 的系统保留端口，也不要选 5432、3306 这类数据库常用端口，避免和目标机器上跑的其他服务撞车。我一般用 12345、 8888、 9090 这类高端口号段，好记且不容易冲突。建议把端口写成常量放配置文件里，别写死在代码里。答辩时老师可能会问“为什么监听地址是 0.0.0.0”，你要能在 10 秒内答出来。

2.4 服务端用户管理：用一个字典维护在线列表

服务端需要维护两个核心结构：一个 dict，key 是客户端 socket 对象（或者客户端 ID），value 是用户昵称；另一个 dict，key 是昵称，value 是对应的 socket。为什么用两个字典？因为广播消息时我需要遍历所有 socket，而私聊消息时需要根据昵称快速定位 socket。

这个需求在数据结构和操作系统课程里叫“双索引结构”，课设答辩时能顺带提一句“这里用双索引是为了平衡两个方向的查找效率”，老师的表情会明显不一样。

服务端的核心逻辑在一次 accept 之后是：启动一个线程专门 recv 这个客户端发来的数据，循环读取消息，根据 type 字段分发处理。这个线程循环是服务端的中枢神经，它的健壮性直接决定你的程序会不会在演示现场崩溃。

3. 服务端实现：广播、转发、掉线感知一次说清

服务端的职责归纳起来只有三件事：接收入网连接、分发消息、感知退出。但把三件事做好，需要你在细节上下足功夫。这一段代码你可以直接抄，抄完要能对着它把逻辑讲出来。

3.1 服务端骨架代码：线程加锁，一个循环走天下

import socket import threading import json class ChatServer: def __init__(self, host='0.0.0.0', port=12345): self.server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.server.bind((host, port)) self.server.listen(5) # 双索引结构：socket -> 昵称，昵称 -> socket self.clients_by_sock = {} self.clients_by_name = {} self.lock = threading.Lock() # 保护共享字典 def broadcast(self, message: dict, exclude_sock=None): """广播，可排除某个 socket（比如发信人自己）""" data = (json.dumps(message) + '\n').encode('utf-8') with self.lock: for sock in list(self.clients_by_sock.keys()): if sock is exclude_sock: continue try: sock.sendall(data) except OSError: self.remove_client(sock, notify=False) def send_to(self, sock, message: dict): data = (json.dumps(message) + '\n').encode('utf-8') sock.sendall(data) def remove_client(self, sock, notify=True): """客户端断开/异常退出时清理""" with self.lock: name = self.clients_by_sock.pop(sock, None) if name and self.clients_by_name.get(name) is sock: self.clients_by_name.pop(name, None) if notify and name: self.broadcast({'type': 'logout', 'sender': name, 'content': ''}) print(f'{name} 已离线，当前在线 {len(self.clients_by_sock)} 人') try: sock.close() except OSError: pass def handle_client(self, conn, addr): """每个客户端一个线程，循环读消息""" buffer = '' while True: try: chunk = conn.recv(4096).decode('utf-8') except (ConnectionResetError, ConnectionAbortedError, OSError): self.remove_client(conn) break if not chunk: self.remove_client(conn) break buffer += chunk while '\n' in buffer: line, buffer = buffer.split('\n', 1) line = line.strip() if not line: continue try: msg = json.loads(line) self.dispatch(conn, msg) except json.JSONDecodeError: print(f'非法消息来自 {addr}，已忽略') def dispatch(self, conn, msg): """消息路由：按 type 字段分发""" mtype = msg.get('type') if mtype == 'login': name = msg.get('sender', '').strip() if not name or name in self.clients_by_name: self.send_to(conn, {'type': 'error', 'sender': 'system', 'content': '昵称已存在或非法'}) return with self.lock: self.clients_by_sock[conn] = name self.clients_by_name[name] = conn self.broadcast({'type': 'chat', 'sender': name, 'content': '进入聊天室'}, exclude_sock=conn) # 给登录用户回一个成功帧，附带当前在线人数 self.send_to(conn, {'type': 'login_ok', 'sender': 'system', 'content': f'欢迎，当前在线 {len(self.clients_by_sock)} 人'}) print(f'{name} 已上线，当前在线 {len(self.clients_by_sock)} 人') elif mtype == 'chat': # 广播消息：发给所有人，包括发信人自己，GUI 层面自行显示 self.broadcast(msg, exclude_sock=None) elif mtype == 'private': target = msg.get('target', '') with self.lock: sock = self.clients_by_name.get(target) if sock: self.send_to(sock, msg) # 回执给发信人，用于本地显示 self.send_to(conn, msg) elif mtype == 'logout': self.remove_client(conn) else: self.send_to(conn, {'type': 'error', 'sender': 'system', 'content': '未知消息类型'}) def start(self): self.server.listen(5) print(f'服务器启动，监听 {self.server.getsockname()}') while True: conn, addr = self.server.accept() print(f'新连接来自 {addr}') threading.Thread(target=self.handle_client, args=(conn, addr), daemon=True).start()

代码里几个容易被忽略但答辩要讲的点：

第一，socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)是干什么的？服务端关闭后立即重启，如果端口还没释放，bind 会报Address already in use，加这一句能让你在调试时不用在系统里等半分钟的 TIME_WAIT 过期。这个坑几乎所有新手都会踩，提前加了避免演示现场重启崩溃。

第二，list(self.clients_by_sock.keys())为什么套一个 list？因为你在 for 循环里调用了remove_client，而 remove_client 会修改字典。Python 里遍历字典的同时删除键值会抛 RuntimeError，先拷贝成一个列表就不会出问题。

第三，为什么所有对共享字典的操作都要加with self.lock？因为服务端是每个客户端一个线程，两个线程同时对clients_by_sock做 pop 和 append，race condition 会让字典结构损坏。线程安全是操作系统课程的核心考点，这一句锁要能讲得出来。

3.2 私聊怎么绕过服务器“偷听”不了消息的错觉

私聊消息在服务端的处理是转发：从发送者的 socket 收上来，解析出 target 字段，查字典找到目标 socket，原样转发。这里有一个细节值得注意：私聊消息要不要给发送者回执？

我在代码里做了双重发送——既发给目标用户，也回发给发送者。原因是客户端 GUI 需要知道“你自己发送的那条私聊内容”并把它显示在聊天窗口里。如果不回执，发送者的聊天记录里就没有自己说过的话，用户会以为消息没发送成功。

这个设计老师可能会作为追问点：“私聊消息经过服务器，服务器本身能看到内容，如果业务上要求端到端加密，你该怎么做？”你可以回答：在应用层做对称加密，服务器只负责转发密文。能答到这里，说明你不是只抄了代码，真的理解了这个方案的边界。

3.3 服务端的半包问题：为什么 break 前要先消费完缓冲区

回到 handle_client 里的 buffer 逻辑。recv 一次最多拿 4096 字节，如果对方一次发了 8000 字节，TCP 会分两次到，第一次 4096，第二次 3904。如果第二次还没到，buffer 里只有半条 JSON，没有换行符，代码不会进入 while 循环，continue之后继续下一次 recv，等数据到齐了再统一解析。

这就是缓冲区存在的意义。很多精简版代码直接json.loads(conn.recv(4096).decode())，多客户端同时发长消息时必然出 bug。你把这个 buffer 思路讲清楚，就是“应用层拆包”的完整答案。

服务端还有一个隐藏需求：客户端异常断开（比如拔网线、关机、断电）。TCP 层面，对端断网时 recv 可能不会立即返回 0，而是长时间阻塞。课设阶段最简单的解法是设置 recv 超时。实际写代码时我倾向于不设超时，而是依赖系统 TCP keep-alive 机制，因为超时时间的选取牵涉到网络环境差异，写短了会把慢客户端误杀。

可以给 conn 设置conn.settimeout(30)，如果 30 秒内没有任何数据（包括心跳帧），recv 会抛socket.timeout，进入异常处理路径做 remove_client。但注意：如果客户端开了 TCP 保活（应用层心跳），服务端不能简单按 30 秒无数据判定掉线。我在第 5 章会专门讲心跳的边界参数。

4. 客户端实现：tkinter 界面与收发线程的恩怨

客户端是用户直接面对的部分，它要做的事比服务端多一层 GUI 交互。好消息是 tkinter 是 Python 标准库自带 GUI 工具，完全不需要 pip install 任何东西。

4.1 客户端单线程会卡死？线程模型决定用户体验

tkinter 有个硬规则：所有 UI 操作必须在主线程里做。如果你在 recv 收到消息后直接调用text.insert()，大概率看到界面假死或弹异常。原因是 tkinter 不允许子线程直接操作主线程的 UI 对象。常见做法是：子线程收到消息后，把消息塞进一个queue.Queue，主线程用root.after(100, poll)周期性检查队列，有新消息才更新界面。

import socket import threading import json import queue import tkinter as tk from tkinter import scrolledtext, messagebox import tkinter.simpledialog as simpledialog class ChatClient: def __init__(self): self.root = tk.Tk() self.root.title('局域网聊天室') self.root.geometry('500x400') self.nickname = simpledialog.askstring('登录', '请输入昵称', parent=self.root) if not self.nickname: exit(0) self.server_host = simpledialog.askstring('服务器', '服务器IP(局域网)', parent=self.root) if not self.server_host: exit(0) self.server_port = 12345 self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.msg_queue = queue.Queue() # UI: 消息展示区 self.text_area = scrolledtext.ScrolledText(self.root, state='disabled', width=60, height=20) self.text_area.pack(padx=10, pady=5) # UI: 输入区 bottom = tk.Frame(self.root) bottom.pack(side=tk.BOTTOM, fill=tk.X, padx=10, pady=5) self.msg_entry = tk.Entry(bottom) self.msg_entry.pack(side=tk.LEFT, fill=tk.X, expand=True) self.msg_entry.bind('<Return>', self.send_message) send_btn = tk.Button(bottom, text='发送', command=self.send_message) send_btn.pack(side=tk.RIGHT) # 连接服务器，登录 self.connect_server() threading.Thread(target=self.receive_loop, daemon=True).start() # 主线程UI轮询队列 self.root.after(100, self.poll_queue) self.root.protocol('WM_DELETE_WINDOW', self.on_close) self.root.mainloop()

注意threading.Thread(..., daemon=True)的细节：daemon 线程不会阻止主线程退出。如果客户端关闭窗口，主线程结束，守护线程会被强制终止，不用手动处理线程回收。如果你写成非守护线程，关窗口时程序会卡在等待 recv 返回，这就是很多人遇到的“窗口关了进程还在”的玄学问题。

4.2 receive_loop 和 send_message：两个线程怎么协作

下面是客户端收发两个核心方法：

def connect_server(self): try: self.sock.connect((self.server_host, self.server_port)) # 连接后立即发送登录帧 login_msg = {'type': 'login', 'sender': self.nickname, 'content': ''} self.sock.sendall((json.dumps(login_msg) + '\n').encode('utf-8')) except Exception as e: messagebox.showerror('连接失败', f'{self.server_host}:{self.server_port} 连接失败: {e}') self.root.destroy() def receive_loop(self): """子线程：循环读socket原始数据，解析成完整消息塞入队列""" buffer = '' while True: try: chunk = self.sock.recv(4096).decode('utf-8') except Exception: self.msg_queue.put({'type': 'system', 'sender': '系统', 'content': '连接已断开'}) break if not chunk: self.msg_queue.put({'type': 'system', 'sender': '系统', 'content': '服务器关闭连接'}) break buffer += chunk while '\n' in buffer: line, buffer = buffer.split('\n', 1) line = line.strip() if not line: continue try: msg = json.loads(line) self.msg_queue.put(msg) except json.JSONDecodeError: pass def send_message(self, event=None): content = self.msg_entry.get().strip() if not content: return self.msg_entry.delete(0, tk.END) msg = {'type': 'chat', 'sender': self.nickname, 'content': content} try: self.sock.sendall((json.dumps(msg) + '\n').encode('utf-8')) except Exception as e: messagebox.showerror('发送失败', str(e))

receive_loop 里的 buffer 逻辑和服务端一模一样的，但要额外小心：self.sock.recv在连接断开时可能抛ConnectionResetError，所以要用 try-except 捕获所有异常，否则 daemon 线程会静默崩溃，界面看起来还在但消息永远收不到。

send_message 在 GUI 线程里直接调sock.sendall，这是安全的吗？答案是够用。TCP 的 sendall 在缓冲区未满时不会阻塞，而且即使阻塞也只是阻塞这一个 GUI 函数，不影响 receive_loop 继续收消息。如果你想更规范，可以把发送也丢给一个专用线程，但课设项目里没必要引入发送队列，答辩时反而要解释额外复杂度。

4.3 poll_queue 更新界面：主线程的 UI 心脏

def poll_queue(self): """主线程每100ms检查一次队列，有消息就更新UI""" try: while True: msg = self.msg_queue.get_nowait() self.display_message(msg) except queue.Empty: pass self.root.after(100, self.poll_queue) def display_message(self, msg): mtype = msg.get('type', 'chat') sender = msg.get('sender', '') content = msg.get('content', '') self.text_area.config(state='normal') if mtype == 'system' or sender == '系统': self.text_area.insert(tk.END, f'[系统] {content}\n') elif mtype == 'chat': self.text_area.insert(tk.END, f'{sender}: {content}\n') elif mtype == 'private': self.text_area.insert(tk.END, f'[私聊] {sender} -> {msg.get("target", "")}: {content}\n') self.text_area.see(tk.END) self.text_area.config(state='disabled')

window.after(100, poll_queue) 是 tkinter 的定时器机制：每 100 毫秒检查一次队列，是标准的“事件驱动 UI”做法。为什么不用time.sleep在子线程里调 UI？因为 tkinter 不是线程安全的，跨线程更新控件在任何 GUI 框架里都是禁忌。你把这个机制在答辩时讲出来，属于“客户端架构设计”的直接证据。

self.text_area.config(state='disabled')是为了让用户在界面上不能编辑历史消息区，但每写入一条消息就得临时改回 normal 再改回 disabled。这行代码看起来笨拙，却是 tkinter 的常规操作，别嫌麻烦删掉，否则用户能随手改掉聊天记录区的内容。

客户端还有个细节：self.msg_entry.bind('<Return>', self.send_message)绑定回车键发送消息，比鼠标点按钮更顺手。这是产品体验层面的加分项，答辩演示时按下回车消息发出去了，比点按钮更有“能工巧匠”的效果。

5. 局域网联调避坑：哪些“玄学”问题其实都有确切原因

这个项目最大的拦路虎不是写代码，而是第一次把两台电脑连在一起时各种“明明代码没问题怎么就连不上”。以下四条是我见过最多、也是课设答辩前后最频繁的翻车现场。

5.1 现象：客户端连接服务器报“Connection refused”

原因 90% 是 IP 地址填错了。很多同学在自己的电脑上测试时填127.0.0.1或localhost，测试通过后忘了改，拿到实验室填的还是这个地址，本机能连但局域网内其他机器全都不行。

解决：服务端监听地址写0.0.0.0，客户端连接地址写服务端机器的局域网 IP。在 Windows 上查这个地址的命令是ipconfig，Linux/macOS 是ifconfig或ip addr。

注意：Windows 可能有多个网卡（无线网卡、有线网卡、虚拟网卡），ipconfig 会列出一串 IP。你要填的是“和客户端在同一网段”的那个 IPv4 地址，一般是192.168.x.x或10.x.x.x开头。

另外检查服务端打印的监听地址，Python 的getsockname()会显示('0.0.0.0', 12345)，这是正常的。如果显示('127.0.0.1', 12345)，说明 bind 参数写错了。

5.2 现象：代码完全一样，换一台电脑就连不上

原因通常是 Windows 防火墙拦截了 TCP 入站连接。Python 进程第一次监听端口时，系统弹窗“是否允许 Python 访问网络”，手速快点了“取消”，之后 Python 的入站连接全部被静默丢弃。

解决：去“Windows 防火墙 → 允许应用通过防火墙 → 更改设置 → 允许其他应用”，找到 Python 的可执行文件，勾选“专用”网络，确定。更省事的方案是临时关掉 Windows 防火墙（仅限实验室场景，结束后立刻打开）。

如果是学校机房管理严格，老师不让你动防火墙设置，可以在服务端启动时打印一行提示：print('请确认防火墙放行端口 12345')，这样演示时万一连不上，你能快速引导老师看这个提示，比干坐着强。

5.3 现象：聊天过程中突然收到一堆拼不起来的乱码消息

原因：我上面的代码是按单一消息一次 recv 的模式写的，但发送端如果连续发送多条消息，比如快速点了五次发送，TCP 可能把这五次 send 合并成一个包发送，服务端一次 recv 拿到的chunk里就有五条完整的 JSON 用换行符分隔。如果用json.loads(chunk)解析整个 chunk，必然失败。

解决：receive_loop 里的 while 循环已经处理了这个问题。核心是每次收到 chunk 先拼到 buffer，再检查 buffer 里有没有换行符，有就切出来一条完整消息。反过来的拆包问题（一条长消息被拆成两次 recv）也由 buffer 机制统一吸收。

如果你在别人的精简代码里看到data = conn.recv(4096).decode()然后直接json.loads(data)的写法，那这个程序在快速连续发消息时一定会崩。这不是玄学，是 TCP 流式传输的内建行为。

5.4 现象：关闭客户端窗口之后，服务器列表里偶尔还显示那个用户在线

原因：客户端点右上角叉号关闭时，WM_DELETE_WINDOW 事件触发 on_close，但 on_close 里如果没有发送 logout 消息就直接销毁窗口，死循环的 recv 会因为连接关闭而抛异常，服务端走 remove_client 路径也能清理，但如果窗口销毁后 socket 连接还没真正关闭，服务端的 recv 会一直阻塞，直到 TCP 超时（默认要几分钟）。

解决：在 on_close 里先发 logout 消息，再 close socket，再销毁窗口。代码要做到“用户主动关闭”和“异常断网”都能在 10 秒内被服务端感知。

如果要求更严格，可以在每帧数据基础上叠加应用层心跳帧：客户端每 30 秒发一个{"type": "heartbeat", "sender": "...", "content": ""}，服务端收到后更新该客户端最近活跃时间。服务端起一个后台线程，每 60 秒扫描一次，发现超过 90 秒没心跳的客户端就强制 remove。这种设计的答辩价值极高，因为它把“故障检测”从应用层做到了。

参数怎么定：心跳间隔 30 秒、扫描周期 60 秒、超时阈值 90 秒。取这三组数的逻辑是——心跳间隔必须小于超时阈值的一半，保证“判定超时前至少能听到三次心跳”；扫描周期取大于心跳间隔的整数，减少扫描线程的唤醒频率。

6. 进阶验证与扩展：让课设从“能跑”变成“能打”

如果你的课设已经能跑通基本聊天，接下来要做两件事：验证你的程序在极端情况下不会崩，以及加一两个让老师眼前一亮的扩展功能。

6.1 压力验证三步走

第一步，同时开五个客户端（可以本机多开），全部登录后互相发消息，验证服务端广播没有漏发和重复。第二步，让其中一个客户端直接拔掉网线（或者按 Ctrl+C 强制杀掉），观察服务端是否在心跳超时后把用户从在线列表移除，其他客户端是否能收到登出通知。第三步，连续发送超过 4096 字节的长消息（比如复制一条 5000 字的小作文），验证 buffer 拆包拼接没有把中文搞乱。

一个很实用的验证技巧：在服务端打印每一帧收到的原始数据，格式是[DEBUG] recv: {"type": "chat", ...}。在测试阶段保持输出，正式演示前关掉。这不是多余的日志，是你答辩时“查问题路径清晰”的底气。

6.2 一个值得加的扩展：私聊与昵称冲突的强化处理

私聊功能我在第 3 章已经给了服务端代码，客户端只需把 send_message 改成可选目标即可。更“聪明”的扩展是：登录时服务端检查昵称，如果重名就拒绝，但如果已经有同名用户离线了，则可以继续使用该昵称。在 remove_client 里清理字典时，用self.clients_by_name.get(name) is sock做一次身份比对，就能避免“新用户抢了旧用户昵称后，旧用户的消息被路由到新用户身上”的边界 bug。

6.3 把聊天程序改成“群聊房间”的边界

如果你想让课设看起来工作量更大，可以把广播改成按房间名称隔离。服务端加一个rooms字典，value 是房间名到客户端列表的映射，客户端发消息时带room字段，服务端按 room 字段找到对应的 socket 列表广播。

这个扩展的代价是：消息帧加一个 room 字段、broadcast 传入目标列表、在线列表会变成每个房间的局部视图。代码改动不超过 50 行，但功能从“一个聊天室”变成“多个独立频道”，答辩时的区分度是质变的。

从这套代码里你应该记住我的习惯：写网络程序前先把消息种类列出来、把每个字段说明白，再动手写 socket 代码。我在带人做课设时，绝大多数人的代码问题不是语法，而是“没有想清楚协议就开始 base 代码”，然后边界 bug 一个接一个，修完一个引出下一个，到答辩前还在补窟窿。

如果你照着本文的方案走完一遍，最理想的状态是：拿到任意一个新题目（比如文件传输、HTTP 代理、局域网群发器），你也能按“定义协议 → 设计消息类型 → 写服务端分发 → 写客户端线程 → 处理边界”这个顺序把它复现出来。这比记住某一篇代码要有用得多。

希望这些踩过的坑能帮你在答辩时少一点紧张，多一点底气。

本文还有配套的精品资源，点击获取