简介：一套基于Spring Boot的桌面聊天室毕业设计项目，包含完整源码与SQL数据库脚本，适合Java学习者、毕业设计学生以及希望快速上手Spring Boot实战的开发者。压缩包共82个文件，大小约4.24MB，主要涵盖Java源码、class编译文件、Jar依赖库、SQL建表脚本及少量界面图片，其中SQL脚本可直接导入MySQL，目录结构清晰，便于逐模块对照学习。目前已有428人学习浏览。整个项目围绕Spring Boot自动配置、Spring MVC请求处理、WebSocket实时通信、数据库表设计以及登录安全控制等关键知识点展开，配合源码和数据库脚本，可帮助读者理解聊天室后端从用户认证到消息存储的完整实现思路。源码中体现的异常处理与项目打包部署方式，也为后续二次开发和上线部署提供直接参考，适合作为课程设计或毕业设计的起步模板，可直接运行或改造。
1. 这个“源码+数据库”的Spring Boot桌面聊天室项目，实际在做一个什么样的系统
从标题看，很多人会先问一句“聊天室为什么不用Node.js，而是拿Spring Boot做桌面客户端？”这其实是毕业设计里最常见的一类选题：技术栈要求走Java，又必须把桌面端、服务端和数据库三样东西都体现出来。这个项目的本质，是一个用Spring Boot充当后端服务、用Swing或JavaFX充当桌面客户端、再用MySQL存聊天记录和用户信息的单体应用。它要解决的不是百万人在线的高性能问题，而是“用户注册、登录、好友列表、一对一聊天、群聊和消息记录查询”这一整套业务闭环。对IT从业者来说，它的价值在于把Spring Boot四层架构、WebSocket推送、数据库连接池和桌面客户端网络编程串在了一条线上；真正难的不是运行压缩包里那个源码+SQL文件，而是看懂后端哪个接口对应客户端哪个按钮、数据库里哪张表存的是历史消息。下面就从拆包开始讲。
2. 拆开压缩包：Spring Boot工程四层结构与桌面客户端的连接方式
2.1 先看项目骨架，再谈代码
拿到基于spring boot的桌面聊天室系统设计与实现（源码+数据库）.7z，第一步不是双击运行，而是把压缩包里的目录结构看明白。绝大多数这类毕业设计压缩包，解压后是三个部分：一个server目录（Spring Boot后端工程）、一个client目录（Swing/JavaFX桌面端）、一个db或sql目录（数据库脚本）。如果你拿到的压缩包只给了后端和SQL，那桌面端通常会以一个独立的Maven工程形式放在另一个目录，说明文档里会写清导入IDE的步骤。
后端工程内部分层一般是这样：
src/main/java/com/example/chat ├── controller/ // 接收HTTP请求，返回JSON ├── service/ // 业务逻辑：登录校验、消息落库 ├── mapper/ // MyBatis的Mapper接口 ├── entity/ // 数据库实体类 ├── config/ // WebSocket、跨域、拦截器配置 └── ChatApplication.java这个分层就是常说的“Spring Boot四层架构”：Controller层只做参数接收和结果封装，Service层写业务规则，Mapper层写SQL，Entity层映射表结构。桌面客户端不直接操作数据库，它只调Controller暴露的REST接口，以及连接WebSocket做实时消息接收。这样设计的好处是，毕业后你想把桌面端改成小程序端，后端一行不用动。
2.2 桌面端与后端的通信方式：REST + WebSocket 双通道
聊天室里有两类数据，一类是低频但需要立即回执的操作，比如登录、注册、加好友；另一类是高频的聊天消息。对于前者用普通HTTP的REST接口就够了，客户端用HttpURLConnection或OkHttp发POST请求，服务器返回JSON。对于后者，如果一直用轮询，服务器压力大且消息延迟明显，所以多数实现会让Spring Boot集成WebSocket协议，桌面端通过WebSocket长连接收发实时消息。
需要注意，Spring Boot的WebSocket和Spring MVC不冲突，可以在一个工程里共用端口。配置好之后，REST接口走的是/api/**，WebSocket走的是/ws/chat，一个负责控制流，一个负责数据流。
2.2.1 最小可用的WebSocket配置类
在Spring Boot 2.7+/3.x里，实现WebSocket有两种方式：一种是用@ServerEndpoint注解，另一种是继承WebSocketConfigurer。毕业设计里我一般建议用WebSocketConfigurer，因为你能同时拿到握手前后的拦截器，方便在后面加登录校验。它的配置代码很短：
@Configuration @EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new ChatWebSocketHandler(), "/ws/chat") .setAllowedOrigins("*") .addInterceptors(new ChatHandshakeInterceptor()); } }这段配置声明了一个URL为/ws/chat的WebSocket服务端点。setAllowedOrigins("*")表示允许任意来源连接，桌面客户端没有浏览器同源策略，所以放开也没问题，但如果以后要接Web前端，建议改成具体域名。ChatHandshakeInterceptor会在握手前执行，可以在里面校验请求参数里带的token，拦截掉未登录的连接。
2.3 Spring Boot工程目录规范：别把客户端代码塞进后端
这类项目的另一个常见问题是目录混乱。有些同学会把Swing界面代码直接放在src/main/java下，和后端Controller混在一起。这样虽然能跑，但当你后面想换一个Web端时，就得把界面代码全部拆出来。正确做法是让后端工程保持一个纯粹的服务端角色，桌面端单独建一个Maven或Gradle工程，只依赖HTTP和WebSocket客户端库。
桌面端技术栈没有强制性要求，Swing对低版本JDK兼容好、上手快；JavaFX界面更现代，但在自定义聊天气泡时也要多写代码。不管用哪种，网络传输层都是同一个逻辑：用一个ChatClient类封装REST登录和WebSocket连接，界面只管拿到消息后刷新列表。
这种“前后端分离”的思路放到桌面聊天室的语境里，就是你在毕业答辩里可以理直气壮解释的那句话：客户端只做展示和交互，所有状态和数据都以服务端为准。
3. 登录、会话与消息收发：WebSocket和REST接口的配合
3.1 登录接口的典型设计与密码处理
先看REST这边。聊天室第一个要用的接口是登录。常见的user表里有user_id、username、password、nickname、avatar。密码不能用明文，至少要用BCrypt或SHA-256加盐存储。Spring Boot工程里可以用spring-security-crypto提供的BCryptPasswordEncoder，只需要引入依赖，不用把Spring Security整套认证机制引进来，不然反而会把毕业设计项目复杂度抬太高。
@PostMapping("/api/login") public Result login(@RequestBody LoginRequest request) { User user = userService.findByName(request.getUsername()); if (user != null && passwordEncoder.matches(request.getPassword(), user.getPassword())) { String token = UUID.randomUUID().toString().replace("-", ""); onlineUserService.put(token, user.getUserId()); return Result.ok(token); } return Result.error("用户名或密码错误"); }这里的onlineUserService是自定义的一个Map实现，作用是把登录成功的token和用户ID做临时绑定。为何要用token而不是直接传用户ID？因为WebSocket握手时你只能放下参数或Header，传一个随机token比传用户ID安全得多。真正项目里会换成Redis，但毕业设计里一个ConcurrentHashMap足够。
3.2 用户列表和会话列表：先搞清楚这两种列表数据的区别
登录进去后，聊天室页面上通常有“在线用户”和“最近会话”两个区域。在线用户来自onlineUserService里活跃WebSocket会话对应的用户；最近会话来自数据库里的conversation表。这两个数据一个放在内存，一个放在MySQL，接口设计时也要分开。
- 获取在线用户：
GET /api/online/list，返回当前在线的用户昵称列表。 - 获取最近会话：
GET /api/conversation/list?userId=xx，返回该用户参与的所有会话及最后一条消息摘要。
提示：很多毕业设计会在“在线用户”这个功能点背后用数据库查询，每5秒刷一次。这样做的缺点是用户关掉窗口后状态不能及时清除。更简单的做法是监听WebSocket的
afterConnectionClosed事件，在会话关闭时把用户从在线Map里移除。
3.3 消息从A到B的完整链路
当用户A向用户B发送一句话，消息的落地流程是这样的：
- 桌面客户端通过WebSocket发送一条JSON消息。
- 后端
ChatWebSocketHandler的handleTextMessage方法拿到文本。 - 解析JSON，判断
targetType是单聊还是群聊。 - 如果是单聊，先查B用户是否在线，在线则直接通过B的WebSocket会话推送过去。
- 无论B在不在线，都要把消息保存到
message表，方便下次拉取历史记录。
下面这段是Handler里保存消息并转发的核心逻辑：
@Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { ChatMessage msg = objectMapper.readValue(message.getPayload(), ChatMessage.class); msg.setFromUserId(currentUserId(session)); // 消息落库 messageService.save(msg); // 查找接收方的WebSocketSession WebSocketSession targetSession = socketSessionRegistry.get(msg.getToUserId()); if (targetSession != null && targetSession.isOpen()) { targetSession.sendMessage(new TextMessage(objectMapper.writeValueAsString(msg))); } }这段代码的要点是currentUserId(session)：因为握手时已经在拦截器里把用户ID写入了WebSocketSession的attributes，所以这里能直接取到。如果你在拦截器里没做这一步，那Handler里就不知道是谁发的消息，这是很多运行报“空指针”的原因。socketSessionRegistry是一个与在线用户Map配套的ConcurrentHashMap<Integer, WebSocketSession>，保存着每个用户当前的连接会话。
3.4 消息格式设计：别只放“内容”两个字段
聊天消息的JSON格式设计看起来简单，实际很容易漏字段。一个能用的消息体至少要包含这些：
| 字段 | 类型 | 说明 |
|---|---|---|
| msgId | Long | 消息ID，前端生成或由后端自动生成 |
| fromUserId | Integer | 发送者用户ID |
| toUserId | Integer | 接收者用户ID，群聊时用它表示会话ID |
| content | String | 文本内容 |
| msgType | Integer | 0文本，1图片，2系统提示 |
| sendTime | Long | 客户端发送时间戳，毫秒 |
| isGroup | Boolean | 是否群聊消息 |
去掉任何一个字段，后面的“已读”“撤回”“按时间拉取历史记录”都会变得别扭。尤其要保存sendTime，而且建议用客户端时间而不是服务端时间，否则用户A和用户B在不同机器上看到的排序会不一致。排序问题靠的是消息ID的自增趋势，而不是发送时间。
4. 数据库不是附属品：表结构、连接配置与初始化数据
4.1 聊天室系统的核心表结构
这个项目的数据库是整个系统的地基，可很多同学把它当成“最后一步”，先把代码跑通了再回头建表，结果字段对不上就反复改Mapper。根据标题里“（源码+数据库）”这个描述，SQL脚本应该是单独提供的，你要做的是先看脚本再启动后端。一个常规聊天室的表至少有这几张。以用户表和消息表为例：
CREATE TABLE `user` ( `user_id` int NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, `nickname` varchar(50) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`user_id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `message` ( `msg_id` bigint NOT NULL AUTO_INCREMENT, `from_user_id` int NOT NULL, `to_user_id` int NOT NULL, `is_group` tinyint NOT NULL DEFAULT '0', `content` text, `msg_type` tinyint DEFAULT '0', `send_time` bigint NOT NULL, PRIMARY KEY (`msg_id`), KEY `idx_to_user_send_time` (`to_user_id`, `send_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有两个容易踩的坑。第一，user表在MySQL里是关键字，建表一定要执行带反引号的语句，否则SQL直接报错。第二，message表的send_time用bigint存时间戳，不要用datetime，因为客户端发送消息会先把时间戳放进JSON，服务端落库时直接存数字即可，查询历史记录时也可以直接用大于小于比较，省掉一次类型转换。
当Service层调用Mapper时，数据库增删改查都写在接口方法里；你在源码里搜索@Select、@Insert、@Update，就能把Controller和SQL一一对上。这种做法也方便你在答辩时讲清“一条消息从界面到表里的路径”。
4.2 连接配置：application.yml里的关键参数
Spring Boot读取数据库连接的地方在src/main/resources/application.yml。下面这份配置需要按你本机的MySQL情况修改：
spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/chatroom?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: yourpassword web: websocket: enabled: true这段配置最值得解释的是URL里的参数。characterEncoding=utf8决定字符串写入数据库时的字符集，如果你的建表语句里已经写了utf8mb4，这里保持一致就不会出现中文乱码；serverTimezone=Asia/Shanghai解决MySQL驱动8.x版本把CST时区解析成美国中部时间的问题。allowPublicKeyRetrieval=true只有在MySQL 8.0以上且用户使用caching_sha2_password认证时才需要，加了能避免连接时抛出“Public Key Retrieval is not allowed”。
如果你在某个新版本Spring Boot里找不到DataSourceAutoConfiguration，不要慌，那属于自动配置类包名变化，和你的业务代码没关系。只要spring-boot-starter-jdbc或mybatis-spring-boot-starter在依赖里，数据源就能自动创建。
4.3 初始化数据与数据库迁移
压缩包里那个chatroom.sql，通常不只是建表语句，还会插几个测试账号。你直接用Navicat或命令行执行它：
mysql -u root -p chatroom < chatroom.sql输入密码后，如果表已经存在，脚本里应该用DROP TABLE IF EXISTS开头，否则会报“Table already exists”。毕业设计里用这种方式初始化没问题，但如果你打算把项目继续演进，建议换成Flyway或Liquibase做迁移管理，这样后续加字段时不用再手写ALTER语句。
注意：
dbx数据库工具或者“数据库同步软件”这类工具可以帮你把本机库和服务器库保持一致，但毕业设计只要守住一条原则：源码里application.yml用的库名、用户名、密码，必须和交付的SQL脚本能对上。我见过很多项目压缩包里的配置连的是root/123456，而SQL脚本里却建了另一个密码，验收时当场翻车。
4.4 为什么“数据库同步软件”在这里不是必需品
项目访问数据库的常见做法是直连MySQL，不需要额外工具。但如果你需要在多台电脑上演示，桌面端打包后的环境里不一定有MySQL；此时可以用H2数据库做演示模式，通过application-demo.yml切换数据源。H2的兼容模式能识别MySQL建表语法，只要把spring.datasource.url改成内存地址，再加一行spring.datasource.driver-class-name=org.h2.Driver即可。
不过这个方法有个前提：SQL脚本里的表名和列名不能用MySQL特有类型，例如engine=InnoDB这种语句在H2里会报错。建议真有这种需求时，先把脚本里的engine和charset这两行删掉，再在H2控制台里执行一遍验证。否则你会发现本地跑得好好的，换环境后连表都建不出来。
5. 从能跑到做好：状态管理、异常处理与接口安全
5.1 退出登录的坑：不要只关客户端窗口
桌面聊天室最典型的逻辑漏洞是“退出登录”只调用System.exit(0)。用户关掉窗口时，WebSocket连接会断开，但REST层面没有告诉服务端“我要下线”。正确做法是在窗口关闭事件里发送一个WebSocket通知，比如{"action":"offline","fromUserId":1}，后端收到后把该用户从在线列表移除。如果你想更笨但更可靠，就在Handler的afterConnectionClosed里做清理：
@Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception { Integer userId = (Integer) session.getAttributes().get("userId"); if (userId != null) { socketSessionRegistry.remove(userId); onlineUserService.remove(userId); // 广播用户下线事件，通知其他客户端刷新在线列表 } }这段代码把连接关闭和业务状态解除绑在一起。你在客户端测试时，可以右键“关闭窗口”正常退出，也可以直接用任务管理器强制结束进程，再回到另一台已登录的窗口，看看在线列表是否都能及时刷新。这部分在线状态管理，也是Java面试里问“WebSocket连接可靠性”时经常被追问的点。
5.2 消息丢失与重连策略
WebSocket连接是长连接，网络抖动时会断。断开期间用户发的消息如果直接丢弃，体验会很差。常见做法是在客户端维护一个“待发送队列”，断线重连成功后重新发送；服务端配合一个msg_id去重，防止同一条消息被处理两次。
if (reconnecting) { pendingQueue.offer(msg); } else { chatClient.send(msg); }reconnecting这个布尔值由客户端的心跳检测决定。服务端在Handler里可以每30秒发一个ping，客户端收到后回pong；如果连续两次收不到pong，服务端主动关闭旧连接，然后客户端发起重连。重连时握手地址要和首次连接保持一致，但不建议把固定token硬编码在重连逻辑里，每次握手都重新走一遍登录校验，刷新token再连，才能避免token泄漏。
5.3 图片与文件消息的落库策略
如果聊天室只做文本，消息表设计得很简单；一旦加图片，问题就来了。图片二进制存MySQL会用BLOB，但会把消息表撑大，且查询性能下降。常见的做法是把图片存到本地磁盘或OSS，然后在content里存一个/upload/123.jpg这样的相对路径，客户端展示时拼接成完整URL。
Spring Boot提供静态资源配置，但需要显式开放上传目录的映射：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir); }uploadDir可以是./upload/，确保服务器运行的工作目录下有这个文件夹。如果你用.7z压缩包交付，最好把upload目录和SQL脚本放在压缩包里，避免演示时头像加载不出来。另外，上传接口要限制文件大小和类型，否则一个超大文件就能把服务端打崩。
5.4 安全边界：Spring Boot Actuator暴露情况要检查
毕业设计里常常引入spring-boot-starter-actuator用来查看健康状态，但如果你不小心把端点全都暴露了，别人就能通过/actuator/env看到你的数据源连接串。在你的application.yml里要限制暴露范围：
management: endpoints: web: exposure: include: health,info这是一个很小的配置，却经常被忽略。还有在WebSocket握手拦截器里校验token时，不要只判断token是否为空，还要判断onlineUserService里有没有该token。未登录的握手请求应该直接返回401状态码，而不是放行后让消息处理逻辑抛空指针。做到这两点，你的项目至少不会被老师一句话问穿。
6. 让“源码+数据库”的交付物更值钱的三个技巧
这个项目到这里，底层的运行逻辑基本就清楚了。接下来不讲基础运行，只讲怎么让这套毕业设计从“能跑”变成“能讲出东西”。第一个技巧是给SQL脚本写清“数据字典”，在脚本开头用注释列出每张表的作用、字段含义、以及和源码里哪个Mapper相对应。这样答辩时老师随机抽一张表，你能立刻说出它的应用价值，而不是对着表名现编。
第二个技巧是给程序加一个“消息转发延迟”的观测点。在ChatWebSocketHandler里加上下面这种耗时统计：
long start = System.nanoTime(); // 转发逻辑 long costMs = (System.nanoTime() - start) / 1_000_000; if (costMs > 50) { log.warn("message {} forward slow, cost {}ms", msg.getMsgId(), costMs); }这个简单的耗时统计，会让你在答“系统性能如何”时有一个能拿出手的数字。配合/actuator/health做存活探活，整个系统的可观测性就比普通毕业设计高出一截。
第三个技巧是保留一份“环境依赖清单”：JDK版本、Maven版本、MySQL版本、端口占用情况，写在一个README.md里。这看起来和代码无关，但却是压缩包交付物里最容易被老师认可“工程化意识”的地方。你可以尝试把群聊用conversation表扩展成group_member关联表，也可以把消息表按时间分区，但毕业设计的完成度主要取决于“链路内所有功能自洽”。按照从解压到跑通、再从跑通到讲清这条路走下来，这个基于Spring Boot的桌面聊天室系统就不再只是标题里的一个项目，而是你能随手改给别人用的一个完整案例。
本文还有配套的精品资源，点击获取
