下载完整项目后，使用idea打开，先运行服务器ChatSever.java,修改chatClient.java和FileTransferManager.java中的ip地址为服务器ip地址,运行test.java
本项目是一个基于 Java 技术栈实现的客户端/服务器（C/S）架构的网络聊天室系统。其核心目标是构建一个功能全面、稳定可靠、可扩展的多用户即时通讯平台。项目不仅要求实现如群聊、私聊、动态用户列表等基本聊天功能，还涵盖了消息持久化、用户漫游、文件传输等一系列高级功能，并对未来的多媒体交互（语音、图片）和复杂社交功能（群内小组）提出了明确的扩展方向。
本项目是关于设计与实现一个基于 C/S 架构的多功能网络聊天室。核心技术栈锁定为 Java Socket 用于底层网络通信，多线程用于处理服务器端的并发用户连接，以及 Java Swing 用于构建客户端的图形用户界面。这是一个经典、能全面考察 Java 核心技术与软件工程思想的综合性课题。
从系统架构上看，关键在于设计一个稳定、高效的服务器端作为整个系统的并发服务枢纽。服务器需负责监听和管理客户端 Socket 连接，实时处理消息路由（群聊广播与私聊点对点转发）、维护在线用户动态状态，并应对用户上下线引发的会话管理问题。因此，并发控制与线程安全成为服务器端设计的首要挑战，任何对共享资源（如在线用户列表）的访问都必须经过严格同步处理，以防止数据竞争和状态不一致。
客户端的核心挑战在于实现 UI 响应与网络通信的解耦。由于网络 I/O 是阻塞操作，必须在独立后台线程中进行，以避免冻结 Java Swing 的事件分发线程（EDT），保证界面流畅和即时响应。客户端还需对多聊天窗口进行有效的状态管理。贯穿整个 C/S 通信的，是需要预先设计一套健壮且可扩展的应用层通信协议，作为功能交互（如登录、消息、文件传输请求等）的基础。
项目需求层次清晰，指明了一条从基础到高级的迭代开发路径。从实现基本文本聊天，到增加文件传输、消息持久化、用户漫游等增强功能，再到探索语音、图片、群内小组等创新功能，要求系统设计具备良好的模块化和可扩展性。
本项目的需求可划分为三个层次，体现了从核心到扩展、从基础到创新的软件开发过程。
需求：群聊、私聊、动态用户列表、在线消息记录、5个窗口限制。
分析：这是项目的“最小可行产品”。技术核心在于服务器端的消息转发逻辑和客户端与服务器的实时通信。服务器需通过中央管理器维护所有在线用户的 Socket 连接，并根据消息类型（群聊或私聊）正确路由。客户端需至少两个线程：UI 线程处理用户交互，后台线程专门接收服务器消息，避免 UI 阻塞。窗口数量限制考验客户端窗口状态管理能力。
需求：消息记录持久化、用户漫游（单点登录）、可配置窗口限制、文件传输。
分析：极大提升系统实用性和健壮性。消息持久化要求服务器引入数据库（如 SQLite）或文件系统存储数据，使系统从“会话级”转变为“持久化”服务。用户漫游要求服务器在处理登录请求时，具备检查并剔除旧连接的能力，保障账户唯一性。文件传输通常需独立的控制信令和数据信道，或为文件传输动态开启新的端口和 Socket 连接。
需求：语音聊天（网络电话）、发送图片、群内小组聊天。
分析：引入更复杂技术和交互模型。语音聊天需从 TCP 转向实时性更高的 UDP，并涉及音频采集、编码、传输、解码和播放，多方会议需中央混音服务器（Mixer）。发送图片对客户端 UI 提出更高要求，包括图片即时预览和内联显示。群内小组聊天要求服务器端数据结构支持“群中群”嵌套，实现更复杂、基于小组的定向消息路由逻辑，对系统架构提出更高要求。
- 用户成功登录并获取信息
- 用户发送群聊消息
- 用户私聊点对点传输文件
本项目遵循经典 C/S 架构，并体现良好的面向对象设计原则：封装、继承和多态。系统可分解为以下关键部分：
- C/S 模型：ChatServer（服务器），ChatClient（客户端）。
- 多线程并发模型：服务器端用 ExecutorService 线程池管理 ClientHandler 实例，为每个客户端分配独立线程。客户端 ChatClient 也用独立 messageListener 线程异步接收消息，避免 UI 阻塞。
- 观察者模式：ChatClient 为 Subject，MessageCallback 为 Observer Interface，HomePageFrame 和 GroupChatFrame 为 Concrete Observer。当 ChatClient 收到新消息，调用回调方法通知所有注册观察者（UI窗口）更新显示，解耦网络逻辑和界面逻辑。
- ChatServer：服务器总控制器。监听端口、接受新连接、创建 ClientHandler、管理在线用户列表、维护离线消息队列、转发私聊和群聊消息、处理登录/登出/注册逻辑。
- ClientHandler：客户端的服务器端代理。独立线程运行，负责与单个客户端通信，解析指令并调用 ChatServer 方法处理，向客户端发送服务器消息。
- FileServer：专用文件服务。独立端口（如9000），处理文件上传和下载请求，与主聊天逻辑分离。
- ChatClient：客户端核心控制器。管理与服务器 Socket 连接，启动监听线程异步接收消息，通过 MessageCallback 回调机制通知 UI 层更新。
- LoginFrame / GistureFrame：应用入口。提供登录/注册界面。验证成功后，创建 Host 和 ChatClient 实例，打开 HomePageFrame。
- HomePageFrame：主界面/导航中心。显示在线用户和群组列表，作为打开私聊和群聊窗口的起点，实现 MessageCallback 接收全局消息。
- ChatFrame / GroupChatFrame：具体聊天窗口。提供聊天界面，包括消息显示区、输入框和功能按钮，处理消息发送和接收。
- FileTransferManager：客户端文件传输工具。封装与文件服务服务器或其他客户端文件传输的底层逻辑。
- user：基础用户类。封装用户名、密码、状态等基本信息和持久化方法。
- Host：当前登录用户类。继承自 user，增加 ChatClient 引用，代表一个活跃、有连接能力的本地用户。
- Group：群组实体类。封装群ID、名称、创建者、成员列表及持久化逻辑。
- Subgroup：小组实体类。封装小组ID、名称、所属群ID、创建者和成员，实现群内小组功能。
本项目采用经典 C/S 架构，遵循面向对象设计原则。
- 服务器端：多线程并发模型，主线程（ChatServer）监听连接，新连接交由独立 ClientHandler 线程处理，实现连接管理与业务逻辑分离。
- 客户端：采用 MVC 设计模式雏形。模型（user, Host, Group, Subgroup），视图（Frame结尾Swing类及自定义组件），控制器（ChatClient，负责网络通信和业务逻辑，通过观察者模式与视图层解耦）。
- 通信协议：自定义基于字符串的应用层协议，特定前缀（如 LOGIN:, SEND:, GROUP_MSG|）和分隔符，定义所有功能交互。
场景：用户点击登录到进入主页，包括服务器端单点登录（踢掉旧连接）逻辑。
- 用户从打开登录界面到进入主页或登录失败的操作路径
- 服务器端 ClientHandler 线程接收并处理客户端消息的内部工作流
项目实现深度依赖于面向对象编程核心思想。通过将各实体和功能模块化为职责分明的对象，项目获得高度的可维护性、可扩展性和代码复用性。下面结合 OOP 四大基本原则分析：
在 ChatClient 类中，底层网络资源如 Socket、BufferedReader、BufferedWriter 及连接状态都为 private，外部无法直接访问。所有与服务器交互必须通过公共接口（如 connect(), disconnect(), sendCommand()）。UI 层只需调用 sendCommand，无需关心协议细节。
user、Group、Subgroup 等数据模型类，所有属性为 private 或 protected，仅能通过公共 get/set 方法访问。类还封装与自身相关的业务逻辑，如 Group 的 addMember、isMember 等方法和文件读写逻辑，使数据持久化与数据模型紧密结合。
Host 类继承 user 类：
public class Host extends userHost 自动获得 user 的所有公共和受保护属性和方法，并扩展了 ChatClient 属性。这种设计完美体现代码复用和逻辑分层。
继承带来的好处：
- 代码复用
- 逻辑清晰
- 易于扩展，如引入管理员用户
MessageCallback 接口的实现：ChatClient 持有 MessageCallback 类型引用，HomePageFrame 和 GroupChatFrame 都实现了该接口。当 ChatClient 收到消息时，调用 messageCallback.onGroupMessageReceived，根据对象实际类型运行对应方法，实现不同窗口的不同响应。
Swing 事件监听器：所有 UI 类实现 ActionListener 接口，重写 actionPerformed 方法，根据事件源执行不同逻辑，也是多态的常见应用。
MessageCallback 接口：定义了所有接收消息组件必须具备的能力（如 onMessageReceived, onUserStatusChanged），仅规定“做什么”，不关心“怎么做”，具体实现交由各类完成。
类公共方法也是一种抽象：如 ChatClient 的 sendMessage 方法，调用者只需知其可发送消息，无需关心底层协议和流操作细节。
通过控制台日志、main 函数等方式对每个类独立功能进行验证。
启动服务器实例和多个客户端实例，模拟真实交互场景，验证如下：
-
登录/登出集成测试：
- 客户端A发送 LOGIN:UserA，服务器 ONLINE 列表应包含 UserA，其他客户端收到 STATUSON:UserA。
- 客户端A发送 LOGOUT:UserA，ONLINE 列表移除 UserA，其他客户端收到 STATUSOFF:UserA。
-
消息转发集成测试：
- 客户端A发送 SEND:UserB:Hello，服务器正确解析并转发，B收到 MSG:UserA:UserB:Hello。
- 客户端A发送 GROUP_MSG|GroupID|Hi All，服务器向群内所有成员广播。
-
单点登录（漫游）测试：
- 客户端A以 "testuser" 登录，B再登录同账号，A收到 ACCOUNT_CONFLICT 被断开，ONLINE 列表中 "testuser" 为 B 的连接。
-
文件传输测试：
- 私聊文件传输：A发起，B接收，验证完整传输与文件内容一致性。
- 群文件传输：A上传，B下载，验证文件列表和下载功能。
在不同计算机或同一台电脑多实例部署服务器和客户端：
- 用户管理：注册、登录/退出是否正常
- 私聊功能：窗口开启、消息收发、离线缓存
- 群聊功能：群创建、加入、消息广播、成员列表
- 动态列表：用户上下线界面自动刷新
- 用户漫游：同账号异地登录原地踢下线
- 聊天窗口限制：窗口数量限制生效
- 文件传输：私聊/群聊文件收发、下载
通过三层测试保障系统从底层类到模块交互再到整体功能全面可靠。
项目由于多人协作开发和版本控制的不熟练，出现较多冗余函数，群聊天消息记录的保存完成了相关函数，但并没有调用导致该功能不可用。作为大二学生，部分史山代码轻点喷，整个项目逻辑还是很简单的，阅读后应该可以轻松删除多余代码和实现新功能。 本次项目群内小组功能未完全实现，提出相关思路：
要实现群内小组功能，需在数据模型中创建 Subgroup 类，包含小组 ID、名称、所属父群组 ID 和成员列表。服务器端，当群成员发起“创建小组”请求时，服务器实例化 Subgroup 并与父群组关联，发送邀请指令给被邀请者。被邀请者选择接受后，服务器更新 Subgroup 成员列表。小组内聊天消息带小组 ID，服务器定向转发给小组所有成员，实现群内私密沟通。