简介仿QQ聊天软件MyQQ源代码是一份基于C#语言开发的即时通讯完整项目示例源自北大青鸟教学体系适合正在学习网络编程与桌面应用开发的中级C#学习者。压缩包整体约11.42MB采用rar格式因上游未提供具体文件统计暂无法列出文件数量及类型明细。项目覆盖用户注册、登录、消息收发、好友管理等典型功能代码中涉及Socket网络通信、多线程处理、消息序列化、ADO.NET数据库操作、Windows Forms界面搭建及async/await异步编程等关键技术点有助于将零散语法知识串联成完整的项目实践。目前已有247人学习下载说明内容具备一定参考价值。开发者可结合源码研究客户端与服务器交互逻辑、数据存储结构及异常处理方式亦可在此基础上扩展群聊、文件传输等进阶功能从而提升对C#实际项目架构与编码规范的理解。1. 仿QQ聊天软件MyQQ为什么一个老项目现在还能拿来练手做 C# 开发的人几乎都绕不过网络编程和数据库这两关而把这两关揉在一起最经典的练习就是仿 QQ 聊天软件。这份北大青鸟完整版的 MyQQ 源代码正好就是一个把客户端、服务端、SQL Server 数据库和 TCP 长连接全部串起来的完整范例。它不是那种只贴几个控件的事件处理代码而是从用户登录、好友列表到单聊、群聊都有的整链路实现。如果你正在学 C#或者准备做毕业设计、课程设计想找一个结构清晰、能看懂又能改的聊天系统源码这份资源很合适。它比网上那些半成品好在你打开解决方案就能看到客户端项目和服务端项目分开组织消息类、数据库访问类、界面窗体各司其职读起来不会一头雾水。当然它是十几年前的代码风格有一些老毛病但正因为有这些毛病才更适合拿来练手、改造和填坑。2. 拿到代码先别急着跑项目结构与核心链路2.1 从登录到会话客户端/服务端的消息流转MyQQ 的架构是老式的 CS 模式客户端负责界面展示和用户输入服务端负责转发消息和管理在线状态。我第一次打开这个解决方案的时候第一反应是找入口文件结果发现它有两个 EXE 项目一个叫 Server另一个是 Client。这种分法很直观服务端启动后监听一个 TCP 端口客户端连接上来就先发登录请求服务端校验用户名密码后返回好友列表和在线状态。消息流转的核心是一条消息类通常叫 Message 或者 Msg里面包含消息类型、发送者、接收者、内容和时间。常见做法是用一个整数做消息类型比如 1 代表登录2 代表好友消息3 代表群聊4 代表下线通知。服务端收到消息后根据类型决定是查数据库还是转发给目标客户端。我在复现的时候注意到这个项目的消息类是用 BinaryFormatter 序列化后直接写到 NetworkStream 的这个做法在 .NET 新一代里已经被标记为过时但在当时是很常见的。// 消息类简化版 [Serializable] public class ChatMessage { public int MsgType { get; set; } // 1登录 2私聊 3群聊 4下线 public int FromUserId { get; set; } public int ToUserId { get; set; } // 群聊时这里放群ID或0 public string Content { get; set; } public DateTime SendTime { get; set; } }这个类的作用是统一客户端和服务端之间传输的数据结构。MsgType 决定了接收方走哪个处理分支FromUserId 和 ToUserId 用来路由Content 存文本。要注意的是这类可序列化的消息类字段名一旦定下来前后端就不能随便改否则旧客户端连新服务端会出现反序列化异常。我在改这个项目时一直保留原字段名只是新增字段就是避免破坏已有数据的兼容性。接着是服务端的核心循环。它维护一个字典key 是用户 IDvalue 是 TcpClient 对应的 NetworkStream每次收到客户端消息就按类型分发。这里最大的问题是它没有像 NetMQ 那类库的消息帧处理直接按流来读所以后面我单独聊拆包粘包的时候会细说。2.2 数据库与数据表用户、好友、消息怎么落库这个项目用的数据库是 SQL Server脚本文件在代码目录下的 db 文件夹里名称一般叫 myqq.sql。表结构不复杂核心三张表Users 用户表、Friends 好友关系表、Messages 消息记录表。登录时只查 Users加载好友列表时要用 Users 和 Friends 做联查离线消息则写入 Messages等好友上线再读取。先看建表脚本里最关键的 Users 表CREATE TABLE [dbo].[Users] ( UserID INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, Password NVARCHAR(50) NOT NULL, NickName NVARCHAR(50) NULL, Signature NVARCHAR(200) NULL, IsOnline INT DEFAULT 0 );这里的 IsOnline 字段其实是冗余的因为在线状态是运行时信息本来应该只放内存里。但那个年代的实现喜欢把它写进数据库方便服务端启动时恢复状态。实际运行中你会发现如果客户端异常断电IsOnline 可能一直停在 1导致用户重新登录时被判定为重复登录。我一般会在服务端启动时执行一条 UPDATE Users SET IsOnline 0把状态清干净。Friends 表是最典型的好友关系表两个字段是 UserID 和 FriendID再加上一个 RelationName 备注名。没有用主键约束来防止反向重复也就是 UserID1、FriendID2 和 UserID2、FriendID1 是可以同时存在的查询时得用 OR 条件。这个设计对初学者来说更容易理解但做双向好友验证时很麻烦后面改造时可以加 CHECK 约束或者用联合唯一索引。Messages 表负责离线消息和聊天记录字段就是 UserID、FriendID、MsgContent、MsgTime。客户端登录后查询条件是 FriendID 当前用户 AND UserID 对方或者反过来这样就能把一对好友之间的历史聊天拉出来。这个项目没有做分页数据量大之后会卡你要是想改进最简单的办法是按 MsgTime 倒序 TOP 50 查最近记录。2.3 配置文件与运行环境先解决连接字符串问题拿到源代码后最容易卡住人的不是编译而是数据库连接字符串。这个项目的连接字符串是写死在代码里的一般是类似“Server.;Databasemyqq;User IDsa;Password123456”这样。你要是直接跑十有八九报“数据库连接失败”。我的建议是第一步就把连接字符串挪到 App.config 里用 ConfigurationManager 读取。这是老项目改造成熟代码的第一步后面你部署到别的机器时不用重新编译只改配置就行。?xml version1.0 encodingutf-8 ? configuration connectionStrings add nameMyQQDB connectionStringServer.;DatabaseMyQQ;User IDsa;Password123456; providerNameSystem.Data.SqlClient / /connectionStrings /configuration然后在代码里写一个 DbHelper 类统一从配置读取连接字符串。这样客户端和服务端都能引用同一个配置不会因为改了服务端的密码而忘记改客户端的。注意这个项目的数据库脚本可能不会自动创建数据库你需要先用 SQL Server Management Studio 执行一次脚本确认生成了 MyQQ 数据库再改配置。还有一点如果你用的是 SQL Server ExpressServer 那部分要写成Server.\SQLEXPRESS实例名不对连不上。这块我在第四节会专门展开因为它是翻车率最高的地方。3. 把聊天跑起来编译、部署与联调3.1 服务端先启动监听端口与客户端连接整个系统要先启动服务端再启动客户端顺序反了客户端会报连接超时。服务端的启动入口一般是一个叫 FormServer 的界面上面有一个“启动服务”按钮后台逻辑是创建一个 TcpListener 并开始监听。默认端口一般是 8888 或 9999代码里写死的你要是改端口客户端那边的 IP 和端口要同时改。为了稳定我建议把监听端口放到配置里并且端口设置得避开常见端口防止冲突。下面是服务端启动的典型代码这个项目里大同小异TcpListener listener new TcpListener(IPAddress.Any, 8888); listener.Start(); this.timerHeartbeat.Start(); // 定时扫描在线客户端 while (true) { TcpClient client await listener.AcceptTcpClientAsync(); Task.Run(() HandleClient(client)); }这段代码的逻辑是监听所有网卡的 8888 端口收到连接后不阻塞主线程交到 HandleClient 里单独处理。HandleClient 是一个死循环不断读取客户端发来的数据流。注意这里用了 async/await原项目可能没有是旧版的 Thread 写法。如果你复现时报编译错误可以把await相关代码换成ThreadPool.QueueUserWorkItem效果一样。端口是稀缺资源在同一台机器调试时你可能会同时跑多个服务端实例后启动的那个会抛异常“地址已被使用”这就是端口被占用的典型现象。可以用 netstat 命令查一下netstat -ano | findstr 8888查到占用端口的 PID 后打开任务管理器结束对应进程或者用taskkill /PID xxx /F杀掉。如果你是第二次启动服务端基本都要走一遍这个排查流程。3.2 客户端登录与好友列表加载客户端启动后的第一个窗口是登录窗体输入用户名密码后点击登录代码里做的动作是建立 TcpClient 连接把登录消息序列化写入流然后等待服务端响应。服务端验证通过后返回用户ID和好友列表客户端再打开主窗体。登录这块最常踩的坑是“点登录没反应”原因多半是服务端没起来或者 IP 写成了 localhost但服务端只监听了某个具体 IP。在调试时客户端和服务端都在本机IP 可以写 127.0.0.1这是我优先推荐的方式。如果是局域网联调客户端要填服务端机器的局域网 IP用 ipconfig 查一下。好友列表的加载是一个典型的数据绑定场景。服务端在用户登录后查询好友联表把每个好友的在线状态带上然后一条条发给客户端。原代码可能是逐个发送效率很低我改成了一次性返回 List 序列化后整体发送。这样网络包数量从 N 次变成 1 次登录明显变快。public class FriendInfo { public int UserId { get; set; } public string NickName { get; set; } public string Signature { get; set; } public bool IsOnline { get; set; } public string StatusText { get; set; } // 在线/离线/忙碌 }客户端收到这个列表后用一个 BindingList 直接绑定到 ListBox 上。ListBox 的 DisplayMember 设置成 StatusText这样界面直接显示“昵称在线”这样的文本。这里有个细节BindingList 必须开单线程使用如果你在异步回调里直接添加项会触发跨线程异常。原项目大多数没有处理我就被这个卡过一晚上。3.3 点对点聊天与群发TCP拆包粘包的典型处理现在的聊天应用都走 WebSocket 或 gRPC但 MyQQ 这种老项目用的是裸 TCP 流。TCP 是流式协议它不保证一次 Send 对应一次 Receive你发 100 个字节对面可能分两次收到 40 和 60你也可能连续发两条消息对面一次就收到 200 字节。这就是拆包粘包。原项目在接收端直接调 stream.Read读多少算多少然后尝试反序列化。这种代码在局域网环境里误打误撞能跑通但消息一密集比如连续发多条表情或长文本就会出现“消息解析失败”或“消息内容错乱”。我做的第一个改造就是自定义一个最简单的帧协议。// 发送端先写4字节长度再写消息体 byte[] body Encoding.UTF8.GetBytes(jsonMessage); byte[] header BitConverter.GetBytes(body.Length); stream.Write(header, 0, 4); stream.Write(body, 0, body.Length);接收端对应的读取逻辑是先读满 4 字节的头部计算出消息体长度再循环读取直到读满 body.Lengthbyte[] lenBuffer new byte[4]; int read 0; while (read 4) { int n stream.Read(lenBuffer, read, 4 - read); if (n 0) throw new Exception(连接断开); read n; } int msgLen BitConverter.ToInt32(lenBuffer, 0); byte[] msgBuffer new byte[msgLen]; read 0; while (read msgLen) { int n stream.Read(msgBuffer, read, msgLen - read); if (n 0) throw new Exception(连接断开); read n; }这个方案的参数很关键包头固定 4 字节用 BitConverter 转成 int注意大小端问题。在 C# 里通过 NetworkStream 的读写只要两端都是 C#BitConverter 默认就是小端互相对得上。如果你以后要接 Java 或 Python 端就得用大端序来发送长度可以用 BinaryWriter 配合 Write(int) 来保证标准处理省得自己搬字节。经过这一改消息接收立刻稳定了连续发几十条都不乱序。我把原来的 BinaryFormatter 也换成了 JSON 序列化一方面是为了更好调式另一方面 BinaryFormatter 在新版本 .NET 中默认被禁不改后面升级框架会直接崩。4. 避坑与常见问题C# 仿QQ项目里的五个经典翻车点4.1 现象登录后立刻掉线反复闪烁原因服务端在客户端登录成功后会给这个客户端设一个心跳计时器但客户端代码里没有发送心跳包或者心跳包格式不对。服务端误以为客户端已下线主动断开了连接。解决在客户端用一个 Timer 每 10 秒发一条 MsgType4 的心跳消息服务端收到后重置该客户端的最后活动时间超过 30 秒没收到就直接清理连接。4.2 现象聊天消息里的中文全部变成“??”或乱码原因客户端发送时用了 Encoding.DefaultGBK 编码服务端接收时用了 Encoding.UTF8 来解码两边编码不一致导致乱码。解决统一使用 Encoding.UTF8并且不只是消息体消息类里所有字符串字段在序列化时都要指定 UTF8。改完后端用记事本打开保存的聊天记录文件确认是 UTF-8 编码而不是 ANSI。从那以后我所有 C# 网络代码都写成new UTF8Encoding(false)避免在非简体中文操作系统上出问题。4.3 现象连接数据库抛“用户 sa 登录失败”或“找不到服务器”原因SQL Server 默认不开启混合认证或者服务器实例名不对。这个项目的连接字符串写的是Server.;User IDsa;Password123456如果你装的是 SQL Server Express实例名是 SQLEXPRESS.解析不到。解决在 SQL Server Management Studio 里右键服务器属性安全性里改为“SQL Server 和 Windows 认证模式”重启服务连接字符串按实例名改好再测试一下sqlcmd -S .\SQLEXPRESS -U sa -P 123456 -Q select name from sys.databases4.4 现象同一台电脑上开两个客户端第二个登录后第一个直接被踢下线原因服务端判断用户是否在线的逻辑是用用户 ID 作为字典 key新连接覆盖了旧连接但旧连接没有被正确关闭。解决在服务端收到重复登录消息时先查字典里的旧流给旧客户端发一条“账号已在别处登录”的消息然后关闭旧连接等它重新连接。注意关闭旧连接时要把它从监听循环里退出否则会继续收到已断开流的异常。我在改造时是用一个 CancellationTokenSource 来控制每个客户端连接的取消比老的 Close 更干净。4.5 现象接收消息时 UI 界面卡死拖不动窗口原因收到消息后直接在网络线程里操作控件没有回到 UI 线程。老 C# 项目最常见的写法是在回调里直接写this.listBox1.Items.Add(...)这在 .NET 2.0 时代不会立刻报错但会间歇性假死。解决用 Control.BeginInvoke 把更新控件的代码封送到 UI 线程执行this.BeginInvoke(new Action(() { listBox1.Items.Add(msg.Content); }));如果代码里有很多地方都要这样写我一般是封装一个UiHelper.RunOnUiThread(Action action)在 Form 初始化时保存 SynchronizationContext特别省事。这个坑不解决后面加任何功能都会显得系统很卡。5. 把这个项目改成能写进简历的样子三个进阶改造先说一个最值得做的改造消息确认机制。原项目的消息是发完就完对方收没收到并不知道。我给聊天协议增加了一种消息类型MsgType 6专门用来做接收确认。客户端收到一条私聊消息后先上屏再回一条确认消息给服务端服务端把这个确认转发给发送方发送方的界面就把消息前面的状态从“已发送”改成“已读”。这个功能在简历上写“实现消息可靠投递”比单纯写“会 Socket 编程”有说服力得多。改造的关键是给每一条消息加一个 GUID 作为消息 ID保存在发送列表里。确认消息不带内容只带 MessageId发送方收到后去匹配自己发的消息如果超时没收到确认就自动重发一次。重发逻辑不要做太复杂最多重试三次否则对方连续掉线会造成队列堆积。这个机制在小规模项目里非常实用也容易讲清楚。第二个改造是把 SQL Server 换成 SQLite。原项目的数据库文件在服务端每次部署都要装 SQL Server太重了。SQLite 是文件型数据库把连接字符串改成Data Sourcemyqq.db就行代码里用 System.Data.SQLite 库所有 SQL 语法基本兼容。要注意的是 SQLite 没有INT IDENTITY(1,1)要改成INTEGER PRIMARY KEY AUTOINCREMENT。改完之后整个服务端变成一个绿色程序拿 U 盘拷走就能跑演示起来方便很多。第三个改造是 UI 层拆成 MVVM。原项目的窗体里到处是btnSend_Click、listBox1_SelectedIndexChanged业务逻辑和界面绑定在一起。你可以只把主窗体的消息列表和发送框抽到 ViewModel用 INotifyPropertyChanged 通知界面。这一步不用全部做完做一部分就能体会好处。我当时只重构了登录窗体和聊天窗体的数据绑定代码从 300 行缩到 120 行后面加“发送文件”功能只改了 ViewModel没动界面。这三个改造做完你就可以把这个项目写进技能列表C# 网络编程、TCP 长连接、自定义协议、SQL 数据库、异步 UI 更新。面试官问起来你能把心跳、粘包、重发机制讲清楚比背十条八股文都管用。最后提一句我从这个项目学到的最大教训任何网络程序第一件事不是写业务而是把消息帧协议定清楚长度、类型、状态码缺一不可。从那以后我每次写通信代码都强制走一遍“帧头 消息体 确认”的流程再没出过消息错乱的幺蛾子。希望这份代码的复现过程也能给你省下同样多的弯路。本文还有配套的精品资源点击获取