简介：这是一套面向JavaWeb初学者与课程设计学习者的网页一对一聊天系统源码，基于JSP、JavaScript、Ajax、Servlet、Tomcat与MySQL实现，重点解决实时消息收发与页面自动刷新问题。聊天页由JSP负责消息显示框、输入框及参数获取，JS与Ajax承担向Servlet发送请求的核心逻辑，除发送自身消息外，还每隔一秒轮询获取更新消息；TalkServlet处理发送请求，TalkFromServlet处理消息刷新，数据库采用MySQL，服务器为Tomcat。资源包共54个文件，包含12个java源文件、12个class、8个jsp页面、7个jar依赖及若干xml配置，压缩包约2.88MB，并附有建库脚本，便于直接导入运行。目前已有348人学习。该资源功能链路完整、结构清晰，适合用来理解Ajax轮询聊天机制、Servlet请求分发与JSP页面交互，也可作为课程设计或入门项目的参考骨架，UI部分尚未设计，留出了自行扩展的空间。
1. 从「消息发出去对方没收到」说起：一对一网页聊天系统到底要解决什么
做 JavaWeb 课设时，最容易被低估的就是「一对一聊天」这四个字。表面看只是两个浏览器窗口互发文字，真动手才发现：HTTP 是无状态的，服务器不会主动找浏览器，消息怎么实时到达？两个人同时在线怎么配对？刷新页面消息会不会丢？这些才是这套方案真正要解决的问题。它面向的是要交课程设计或毕业设计的学生，也适合想快速搭一个可演示即时通讯原型的开发者。整套系统围绕「登录鉴权 → 建立会话 → 消息投递 → 历史留存」这条主线展开，用 JavaWeb 技术栈把一对一聊天的完整链路跑通，而不是停留在「能发一条消息」的演示层面。
2. 需求与技术选型：为什么不用轮询硬扛，而选 WebSocket
2.1 先把功能边界划清楚
一对一聊天听起来简单，但一份能交差的方案必须把边界写死，否则做到一半就会发现需求在膨胀。我一般会把功能拆成「必须做」和「明确不做」两栏，写进设计文档的第一页。必须做的部分包括：用户注册登录、在线用户列表、点击某个用户发起一对一对话、消息实时收发、聊天记录按会话存储并在重新进入时加载、基本的输入校验（空消息、超长消息拦截）。明确不做的部分同样重要：群聊、文件传输、消息撤回、已读回执这些都属于加分项而非核心，课设阶段硬塞进去只会让主线做不完。
把边界划清之后，数据模型就顺理成章了。核心只有三张表：用户表存账号密码和昵称，会话表记录「谁和谁」的对话关系（用两个用户 ID 的有序组合保证 A 找 B 和 B 找 A 是同一条会话），消息表存每条消息的发送者、接收者、内容、时间戳和所属会话。会话表的存在是关键设计点——如果只靠消息表里的一对用户 ID 去反查，每次打开聊天窗口都要做一次范围扫描，数据一多就慢；单独建会话表相当于给对话建了索引，加载历史记录时直接按会话 ID 查，干净利落。
2.2 实时通信的选型：WebSocket 对比轮询
这是整套方案里最值得讲清楚的一个决策。很多同学第一反应是用 Ajax 定时轮询，每隔一两秒问一次服务器「有没有新消息」。这种做法能跑，但问题很明显：消息延迟取决于轮询间隔，间隔短了服务器压力大，间隔长了体验差；而且大部分请求都是空手而归，白白消耗连接资源。放到答辩场景里，老师一问「你这个实时性怎么保证的」，轮询方案很难自圆其说。
WebSocket 走的是另一条路：客户端和服务器通过一次 HTTP 握手升级协议，之后保持一条长连接，双方都能主动推送数据。消息从发送方到接收方几乎是即时的，服务器也不用反复处理无效请求。JavaWeb 生态里，Java EE 7 之后内置了 JSR-356 的 WebSocket API，用@ServerEndpoint注解就能声明一个端点，不需要额外引入第三方库，这对课设环境特别友好——Tomcat 8 以上直接支持，部署时不用折腾依赖。
选型上还要说清楚会话管理怎么做。WebSocket 端点本身是无状态的，每个连接对应一个端点实例，但我们需要知道「这个连接属于哪个用户」，才能在收到消息时准确投递给对方。通常的做法是在握手阶段从 HttpSession 里取出登录用户信息，存进一个全局的在线连接表（ConcurrentHashMap<用户ID, Session>），发送消息时按接收者 ID 查表拿到对应的 WebSocket 会话再推送。这里必须用线程安全的容器，因为多个连接会并发读写这张表，用普通 HashMap 迟早出问题。
2.3 技术栈清单与版本约束
整套系统采用典型的 JavaWeb 分层结构，前端用原生 HTML/CSS/JavaScript 配合 WebSocket API，不引入前端框架，降低课设的构建复杂度；后端用 Servlet 处理登录注册等常规请求，用 WebSocket 端点处理聊天消息；数据层用 JDBC 直连数据库，配一个简单的连接池。下面这张表把各层的职责和技术点对齐，方便照着搭骨架。
| 层次 | 技术选型 | 职责 | 关键约束 |
|---|---|---|---|
| 表现层 | HTML + 原生 JS + WebSocket API | 登录页、聊天页、消息渲染 | 浏览器需支持 WebSocket |
| 控制层 | Servlet 3.1+ / WebSocket 端点 | 登录鉴权、消息路由 | Tomcat 8 及以上 |
| 服务层 | 普通 Java 类 | 用户校验、消息持久化 | 与 Web 层解耦 |
| 数据层 | JDBC + 连接池 | 用户、会话、消息读写 | 数据库字符集用 utf8mb4 |
版本上有个血泪经验：WebSocket 依赖 Servlet 3.1 和 Java 7 以上，如果实验室的 Tomcat 还是 7.x，@ServerEndpoint根本不会被扫描到，端点注册不上，前端连过去直接 404。动手前先确认容器版本，比写到一半再排查省事得多。
3. 总体架构与数据库设计：三层结构如何承载一条消息的完整旅程
3.1 分层结构与消息流转路径
系统按表现层、控制层、服务层、数据层四层组织，但真正体现设计功力的是「一条消息从发出到落库再到对方屏幕」的完整路径。发送方在聊天页输入文字点击发送，前端通过已建立的 WebSocket 连接把消息封装成 JSON 发出去；服务端的 WebSocket 端点收到后先做校验（发送者是否在线、接收者是否存在、内容是否为空或超长），校验通过后调用服务层把消息写入消息表，同时更新会话表的最后消息时间；落库成功后，端点从在线连接表里查接收者的 WebSocket 会话，如果对方在线就立即推送，不在线则消息静静躺在数据库里，等对方下次登录加载历史时再出现。
这条路径里有两个容易忽略的设计点。第一，落库和推送的顺序必须是「先落库、后推送」，反过来一旦推送成功但落库失败，对方看到了消息、刷新后却消失了，这种 bug 极难复现也极难解释。第二，推送失败不能影响主流程，接收者可能刚好断线，此时捕获异常、记录日志即可，消息已经落库，不会丢。把这两点写进设计文档，答辩时被问到「消息可靠性怎么保证」就有话可说。
3.2 数据库表结构与索引设计
三张核心表的字段设计直接决定后续查询效率。用户表的密码字段必须存哈希值而不是明文，课设里用 SHA-256 加盐就够，别图省事存明文，这是答辩必被挑的点。会话表用user_a和user_b两个字段，约定user_a < user_b，这样无论谁发起对话，会话记录唯一，避免同一对用户产生两条会话。消息表除了基本字段，还要加一个session_id外键关联会话，加载历史时按会话 ID 加时间排序，一条 SQL 搞定。
-- 用户表：密码存哈希，昵称用于展示 CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, nickname VARCHAR(32) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 会话表：约定 user_a < user_b，保证一对用户只有一条会话 CREATE TABLE t_session ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_a BIGINT NOT NULL, user_b BIGINT NOT NULL, last_msg_at DATETIME, UNIQUE KEY uk_pair (user_a, user_b) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 消息表：按会话查询历史，联合索引覆盖排序 CREATE TABLE t_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id BIGINT NOT NULL, from_user BIGINT NOT NULL, to_user BIGINT NOT NULL, content VARCHAR(1000) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_session_time (session_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段建表语句里，uk_pair唯一索引是防止重复会话的兜底，idx_session_time联合索引让「按会话查历史并按时间排序」走索引而不是全表扫描。字符集统一用utf8mb4而不是utf8，因为后者在 MySQL 里实际只支持三字节，用户发个表情符号就会报错或乱码，这个坑踩过的人都懂。字段长度也要留余量，消息内容给到 1000 字符，前端同步做长度校验，避免超长内容撑爆字段。
3.3 在线连接表的设计与并发考量
在线连接表是 WebSocket 方案的中枢，它的结构看似简单，实则决定了消息能不能准确送达。用ConcurrentHashMap<Long, Session>以用户 ID 为键存 WebSocket 会话，用户上线时 put，下线时 remove。这里有几个细节：同一个用户可能在多个标签页登录，如果直接覆盖，旧连接就收不到消息了，通常的做法是允许一个用户对应多个会话，用Map<Long, Set<Session>>或者干脆在推送时遍历所有该用户的会话；用户断线时要在@OnClose回调里清理，否则表里会残留失效会话，推送时抛异常。
并发方面，ConcurrentHashMap保证了单个操作的原子性，但「检查是否存在再放入」这种复合操作仍需注意，用computeIfAbsent之类的原子方法更稳妥。另外，推送消息时如果直接在主线程里同步发送，某个慢连接可能拖住整个处理流程，稳妥的做法是把推送放到独立线程池里异步执行，主流程只管落库。这些细节在课设文档里写出来，能明显拉开和「能跑就行」方案的差距。
4. 核心模块实现：从登录鉴权到消息推送的代码落地
4.1 登录鉴权与 HttpSession 的衔接
WebSocket 握手阶段拿不到表单参数，只能依赖握手请求里携带的 Cookie，所以登录必须走传统的 Servlet 会话机制。用户提交账号密码后，服务端校验哈希、把用户信息写进 HttpSession，后续 WebSocket 握手时通过HttpSession取出用户身份。这里的关键是 WebSocket 端点如何访问 HttpSession——JSR-356 提供了ServerEndpointConfig.Configurator的modifyHandshake方法，可以在握手时把 HttpSession 里的属性复制到端点实例上。
public class AuthConfigurator extends ServerEndpointConfig.Configurator { @Override public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest request, HandshakeResponse response) { // 从握手请求中取出 HttpSession，拿到登录用户 ID HttpSession httpSession = (HttpSession) request.getHttpSession(); if (httpSession != null) { Object userId = httpSession.getAttribute("userId"); // 存入端点配置的用户属性，供端点实例读取 config.getUserProperties().put("userId", userId); } } }这段配置类的逻辑是：握手发生时，从请求里取出服务端会话，把登录时写入的userId转存到 WebSocket 端点的用户属性里。端点实例在@OnOpen时通过session.getUserProperties().get("userId")就能拿到当前连接属于谁。参数上要注意getHttpSession()可能返回 null（比如客户端没带 Cookie），必须判空，否则握手阶段直接空指针。另外，如果登录用的是自定义 Token 而不是 HttpSession，就要改成从请求头或查询参数里解析，思路一致，取身份的方式不同而已。
4.2 WebSocket 端点的连接生命周期管理
端点类承担连接建立、消息接收、连接关闭三个回调。@OnOpen里把当前会话登记进在线表，@OnMessage里解析消息并走落库加推送，@OnClose里清理在线表。下面这段是核心骨架，重点看消息处理的分支逻辑和异常兜底。
@ServerEndpoint(value = "/chat", configurator = AuthConfigurator.class) public class ChatEndpoint { // 在线连接表：用户ID -> 该用户的所有连接（支持多标签页） private static final Map<Long, Set<Session>> ONLINE = new ConcurrentHashMap<>(); private Long userId; @OnOpen public void onOpen(Session session) { this.userId = (Long) session.getUserProperties().get("userId"); if (userId == null) { // 未登录的连接直接关闭，避免匿名连接占用资源 try { session.close(); } catch (IOException ignored) {} return; } ONLINE.computeIfAbsent(userId, k -> ConcurrentHashMap.newKeySet()).add(session); } @OnMessage public void onMessage(String raw, Session session) { // 解析 JSON：{"to": 接收者ID, "content": "消息内容"} JSONObject json = JSON.parseObject(raw); Long to = json.getLong("to"); String content = json.getString("content"); // 基础校验：空内容、超长、接收者不存在都直接拒绝 if (content == null || content.trim().isEmpty() || content.length() > 1000) { return; } // 先落库，再推送；落库失败则整条消息作废 MessageService.save(userId, to, content); push(to, buildPayload(userId, content)); } private void push(Long to, String payload) { Set<Session> targets = ONLINE.get(to); if (targets == null) return; // 对方不在线，消息已落库，等其上线加载 for (Session s : targets) { if (s.isOpen()) { // 异步发送，避免慢连接阻塞当前处理线程 s.getAsyncRemote().sendText(payload); } } } @OnClose public void onClose(Session session) { Set<Session> set = ONLINE.get(userId); if (set != null) { set.remove(session); if (set.isEmpty()) ONLINE.remove(userId); } } }这段代码里几个设计点值得展开。ONLINE用Map<Long, Set<Session>>而不是一对一映射，是为了支持同一用户多标签页在线，推送时遍历集合逐个发送。onOpen里对未登录连接直接关闭，防止匿名连接堆积。onMessage的校验放在落库之前，空消息和超长消息不进数据库。推送用getAsyncRemote()而不是getBasicRemote()，前者非阻塞，后者同步发送在慢网络下会卡住处理线程。onClose里清理时先移除会话再判断集合是否为空，避免内存泄漏。这些细节单看都不起眼，组合起来才是一个能扛住演示的端点。
4.3 消息持久化与历史记录加载
消息落库走服务层，用预编译语句防注入，同时更新会话表的最后消息时间。加载历史时按会话 ID 查询，分页返回，前端渲染成气泡列表。这里有个体验细节：进入聊天窗口时先加载最近 N 条（比如 50 条），往上滚动再加载更早的，避免一次性拉全量把页面卡死。会话列表页则按last_msg_at倒序展示，让最近聊过的人排在最前面，这个排序字段就是会话表里那个last_msg_at的用武之地。
public class MessageService { public static void save(Long from, Long to, String content) { long sessionId = SessionService.getOrCreate(from, to); String sql = "INSERT INTO t_message(session_id, from_user, to_user, content) VALUES(?,?,?,?)"; try (Connection conn = DataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setLong(1, sessionId); ps.setLong(2, from); ps.setLong(3, to); ps.setString(4, content); ps.executeUpdate(); } catch (SQLException e) { throw new RuntimeException("消息落库失败", e); } // 更新会话最后活跃时间，供会话列表排序 SessionService.touch(sessionId); } }getOrCreate负责按「小 ID 在前」的规则查会话，没有就建一条，保证同一对用户永远只有一条会话记录。touch更新last_msg_at，让会话列表的排序实时反映最新对话。异常处理上，落库失败直接抛运行时异常，让上层感知并拒绝推送，宁可这条消息发不出去，也不能出现「对方看到了但数据库里没有」的假象。参数说明：from和to都是用户 ID，content已经过长度校验，sessionId由会话服务统一分配。
5. 避坑与排查：一对一聊天最容易翻车的五个地方
5.1 现象：前端连 WebSocket 一直 404 或握手失败
原因通常有两个：一是容器版本不够，Tomcat 7 不支持 JSR-356，@ServerEndpoint不会被扫描；二是端点路径和前端new WebSocket()里的地址对不上，比如应用部署在/chatApp上下文下，前端却连了根路径。解决方式是先确认容器版本，再把前端连接地址写成「协议 + 主机 + 上下文 + 端点路径」的完整形式，用ws://而不是http://，部署到 HTTPS 环境则换成wss://。
5.2 现象：消息发出去了，对方在线却收不到
先查在线表里有没有对方的记录。常见原因是握手时userId没取到，端点里userId为 null，连接被onOpen直接关掉了，但前端没感知，看起来像「连着却收不到」。排查时在onOpen里打日志确认userId是否为空，再检查登录时写入 HttpSession 的属性名和握手时读取的是否一致。另一个可能是多标签页场景下只存了一个会话，旧连接被覆盖，改成集合存储即可。
5.3 现象：中文和表情符号乱码
数据库字符集用了utf8而不是utf8mb4，四字节字符存不进去；或者 JDBC 连接串没指定字符集。解决方式是建库建表统一utf8mb4，连接串加上characterEncoding=utf8，前端页面声明charset=utf-8。三处对齐之后乱码基本绝迹，这个坑在演示时特别致命，用户发个表情直接报错，场面很尴尬。
5.4 现象：刷新页面后聊天记录全没了
消息只在前端内存里存着，没落库，或者落库了但加载历史时查询条件写错。检查save是否真的执行了executeUpdate，再检查加载历史的 SQL 是否按session_id过滤并按时间排序。还有一种情况是会话 ID 每次重新计算导致对不上，根源在会话表的「小 ID 在前」规则没统一，A 找 B 和 B 找 A 算出了两条不同会话。
5.5 现象：用户关掉页面后，再登录发现对方发的消息丢了
这通常不是丢消息，而是离线消息的加载逻辑没做。对方不在线时消息已经落库，但用户重新登录后只加载了「当前会话」的历史，没有把离线期间的新消息拉出来。解决方式是在进入会话时按last_msg_at或消息时间增量加载，或者干脆每次进入会话都重新拉最近 N 条，简单可靠。课设阶段不必做复杂的未读计数，保证「重新进来能看到」就够。
6. 验收与答辩：怎么证明这套聊天系统真的跑通了
验收这件事，最忌讳的是「演示时刚好能发一条消息」就交差。我一般会准备一份验收清单，按功能点逐条过，每条都设计一个能当场复现的操作路径。登录注册要验证错误密码被拒、重复用户名被拒；在线列表要验证两个账号登录后互相可见、退出后消失；消息收发要验证双向都能即时到达，且发送方和接收方的消息顺序一致；历史记录要验证刷新页面、退出重登后消息仍在；异常场景要验证空消息发不出去、超长消息被拦截、对方离线时消息不丢。这份清单同时也是答辩时老师可能追问的点，提前跑一遍，心里有底。
答辩陈述有个技巧：不要从「我用了什么技术」讲起，而要从「一条消息怎么走完全程」讲起。用一张消息流转图（发送方 → WebSocket 端点 → 校验 → 落库 → 在线表查接收者 → 推送 → 接收方渲染）把主线串起来，中间穿插你做的关键决策——为什么选 WebSocket 不选轮询、为什么先落库后推送、为什么会话表要约定小 ID 在前。老师听到这些「为什么」，就知道你不是照抄教程，而是真的想过。下面这张表可以整理成答辩时的对照卡。
| 验收项 | 操作路径 | 预期结果 | 对应设计点 |
|---|---|---|---|
| 登录鉴权 | 错误密码登录 | 提示失败，不建会话 | 密码哈希校验 |
| 实时收发 | 双账号互发消息 | 对方即时收到 | WebSocket 推送 |
| 离线消息 | A 发消息时 B 离线，B 再登录 | B 能看到该消息 | 先落库后推送 |
| 历史加载 | 刷新聊天页 | 最近消息仍在 | 按会话查消息表 |
| 异常拦截 | 发送空消息/超长消息 | 被拒绝，不入库 | 端点前置校验 |
演示环境也要提前踩点。实验室机器可能装的是旧版 Tomcat，或者数据库没开远程访问，这些都要在答辩前一天跑通。我习惯把部署步骤写成脚本，从建库、导表、改连接串到启动容器一条龙，现场出问题能快速重来。还有个小细节：演示时用两个浏览器（或一个正常窗口加一个隐私窗口）登录两个账号，比开两台机器稳，也方便老师同时看到双方界面。
从那以后我每次带课设验收，都强制自己先按清单完整走一遍，再让同学演示——因为我自己踩过「演示时一切正常、老师随手一测就崩」的坑，那种当场卡壳的滋味不好受。希望这套结构和清单能帮到你，把一对一聊天系统从「能跑」做到「能讲清楚为什么这么跑」。
本文还有配套的精品资源，点击获取
