微信小程序心理咨询聊天室毕设：架构、WebSocket与避坑指南

简介一份学校心理咨询聊天室微信小程序毕业设计资料包含完整源码、说明文档和演示录像。项目基于微信开发者工具和 Java SSM 框架构建后端使用 MySQL 存储数据整体分为微信小程序端与后台管理端。小程序端面向大学生提供用户注册与登录、心理文章浏览、心理医生列表查看、在线咨询提交与回复以及聊天室互动发言等后台端由管理员使用负责用户信息验证、健康信息管理、公告发布并可对聊天信息进行回复或删除。资源包为 RAR 格式共含 1342 个文件压缩后约 28.57MB主要文件类型为 Vue 页面、Java 类、JavaScript 脚本、WXML/WXSS 小程序页面、JSON/XML 配置、PNG/JPG 图片及 SQL 数据库脚本等目录结构按前后端模块划分便于索引查找。目前已有 370 人学习下载提供的源码、说明文档和演示录屏能帮助理解系统设计与业务逻辑也方便在此基础上进行二次开发适合毕业设计、课程设计或个人项目实战。1. 微信小程序毕业设计做心理咨询聊天室这个项目到底值不值得选如果你正在为毕业设计选题发愁又不想做那种「登录 一个列表 一个详情页」的模板型小程序那「学校心理咨询聊天室」这个方向值得认真考虑。它的核心不是聊天本身而是把咨询场景里的匿名身份、值班导师、敏感词预警、消息审核这些真实业务规则一件件落到小程序前端和后端服务里——做完以后你能讲清楚的东西比一个普通聊天室多出一整层。这个题的工程量也刚好卡在毕设的合理区间小程序端要写页面和交互后端要有 WebSocket 服务和消息存储还要考虑掉线重连、消息重复、记录查询这类实战问题。评审老师关心的是「你自己的代码在哪里、解决了什么问题」而不是功能有多花哨。一个能现场演示断线重连、消息不重不漏、敏感词触发预警的聊天室比堆十个页面更有说服力。后面几章我就按我自己带毕设时常用的方案把技术选型、代码结构和踩过的坑完整拆开讲从零到一能跑通为止。2. 先把架构立住聊天室不是「登录 发消息」这么简单2.1 小程序端技术选型为什么原生写法对毕业设计最稳妥很多同学一上来就想用第三方跨平台框架理由是「写起来快」。但我的建议很直接这个项目老老实实用微信小程序原生 WXML / WXSS / JavaScript 写最多在工具库层面引入一个自己封装的请求模块不要引入整套 UI 框架。原因有三条。第一毕业设计的源码是要被评阅老师翻开逐行看的原生代码结构清晰每个文件对应一个页面或一个模块老师能直接看出你的工作量引入框架之后老师点开几十个依赖文件反而说不清哪些是你写的。第二原生小程序的基础能力对聊天室场景完全够用scroll-view做消息列表input做输入框wx.login做登录态官方 API 都能覆盖不需要框架提供的额外封装。第三第三方框架在真机预览时偶尔会出现样式兼容问题而毕设演示最怕的就是「开发者工具里好好的手机上一打开就白屏」。页面结构上我一般会拆成四个登录/角色选择页、房间列表页、聊天页、我的记录与评价页。聊天页是核心后面单独讲。这里有一个容易忽略的点咨询场景下用户不一定是学生还可能是值班导师所以页面要做角色区分至少要在登录后有一个角色标识后续的消息渲染、快捷回复、审核操作都依赖这个标识。角色分配的逻辑放在后端做前端只展示不要在前端写死。2.2 通信方案对比WebSocket 还是 HTTP 轮询各踩过什么坑聊天室的消息通道只有两个选择WebSocket 长连接或 HTTP 定时轮询。我的结论是答辩想拿高分就上 WebSocket但必须把心跳和断线重连写好如果时间确实不够轮询也能跑不过你要能说清楚为什么在低并发场景下轮询「够用」。轮询的实现思路是前端每 23 秒调一次接口拉取新消息代码量确实少服务端就是一个普通查询接口。但它有两个明显问题一是消息延迟是固定的轮询间隔用户会觉得「卡」二是每次轮询都会打到后端接口并发上来后数据库压力明显。心理咨询场景本身消息频率不高轮询能跑但演示的时候老师如果问「为什么不用 WebSocket」你只能承认是为了省事。WebSocket 的工程量其实也就多一两百行代码核心是三步建立连接、收发消息、断线重连。断线重连是最容易翻车的地方后面避坑章节会细讲。这里先记住一条原则WebSocket 只负责实时消息推送登录、历史记录、敏感词审核这些操作仍然走普通 HTTPS 接口不要让所有业务都挤在 WebSocket 里那样调试起来会非常痛苦。2.3 数据库设计消息表、角色表和咨询场景的四个独特约束聊天室的消息表结构看起来简单但咨询场景会多出几个普通聊天室没有的字段。先看我常用的表结构字段类型说明msg_idvarchar(64)客户端生成的消息唯一 ID用于幂等去重room_idvarchar(32)房间 ID一次咨询会话对应一个房间sender_roletinyint1 学生来访者2 值班导师3 系统通知sender_namevarchar(32)匿名昵称或导师工号contenttext消息内容msg_typetinyint1 文本2 图片3 系统提示is_auditedtinyint敏感词审核状态0 待审1 通过2 触发预警create_timedatetime消息时间对比普通聊天室这里多了三个咨询场景特有的设计。一是msg_id必须由客户端生成而不是依赖数据库自增这样弱网重发时服务端才能识别重复消息二是sender_role把来访者和导师分开前端渲染气泡样式、后端做权限控制都靠它三是is_audited字段咨询场景下消息不能完全实时直达涉及自伤、自残等敏感词的消息要先触发预警流程。除此之外还需要两张辅助表一张是值班导师表记录导师的在线状态和当前服务房间号用来实现「导师忙请稍候」的排队提示另一张是敏感词表存触发预警的词汇和对应的紧急程度。预约功能如果要做再单独加一张预约表这个后面说。服务端我常用的是 Node.js WebSocket 库 MySQL轻量、好演示、代码量适中。用 Java Spring Boot 也可以但对毕设来说偏重而且启动和部署的演示环节容易出岔子。3. 小程序端从零跑通登录、聊天页与业务规则落地3.1 登录与角色分配匿名来访者如何不撞名、不泄露身份心理咨询的第一条规则是匿名。小程序端不能用真实微信号直接当昵称展示也不能要求用户填写姓名学号。常见做法是用户进入时选角色来访者或导师。来访者由后端生成一个随机匿名代号比如「同学 A017」导师则绑定自己的工号。这样页面展示的永远只有代号但数据库里能对应到具体会话记录。小程序端的登录代码长这样// pages/login/login.js const app getApp() Page({ data: { role: 1, // 默认来访者 }, // 选择角色后调用微信登录拿 code 换后端登录态 onRoleTap(e) { const role Number(e.currentTarget.dataset.role) this.setData({ role }) }, onLoginTap() { wx.login({ success: async (res) { if (!res.code) { wx.showToast({ title: 获取登录凭证失败, icon: none }) return } // 把微信登录 code 和角色一起发给后端 const loginRes await app.request({ url: /api/login, method: POST, data: { code: res.code, role: this.data.role, }, }) if (loginRes.code 0) { // 后端返回 token 和匿名昵称存入本地缓存 wx.setStorageSync(token, loginRes.data.token) wx.setStorageSync(nickname, loginRes.data.nickname) wx.setStorageSync(role, loginRes.data.role) wx.redirectTo({ url: /pages/room-list/room-list }) } }, }) }, })这段代码里要注意三个点。第一wx.login拿到的code有效期只有 5 分钟而且只能使用一次所以拿到后要立刻发给后端换取登录态后端用这个code调微信接口换openid前端不接触openid避免在客户端暴露用户身份。第二角色选择必须在登录请求之前完成因为后端要根据角色决定返回的是匿名代号还是导师身份。第三登录成功后前端只保存后端返回的token和nickname不要额外存储任何真实身份信息这是心理咨询项目的隐私底线。后端登录接口的伪代码逻辑是收到code后调微信接口换openid查询数据库看该openid是否已存在不存在就按角色创建新用户来访者生成随机代号导师查找已有的导师账号存在则直接返回已有身份。这里有一个常见的坑同一个用户在不同时间进入会被识别成不同匿名代号如果项目要求「老用户回来能继续看历史记录」就要靠openid映射到同一个匿名身份但不能把这个映射关系暴露到前端。3.2 聊天页核心代码消息发送、渲染与滚动定位聊天页是这个项目工作量最大的页面核心功能是消息列表的渲染、发送消息、滚动到底部。很多同学在这里第一次遇到「明明 setData 了数据页面却不滚动」的困惑所以我把关键实现完整贴出来。先看 WXML 结构!-- pages/chat/chat.wxml -- view classchat-page scroll-view classmsg-list scroll-y scroll-into-view{{scrollIntoId}} scroll-with-animation bindscrolltoupperonLoadMore view wx:for{{msgList}} wx:keymsgId idmsg-{{item.msgId}} view classmsg-row {{item.senderRole 1 ? left : right}} view classmsg-nickname{{item.senderName}}/view view classmsg-bubble{{item.content}}/view /view /view /scroll-view view classinput-area input value{{draft}} bindinputonInput bindconfirmonSend confirm-typesend placeholder输入内容回车发送 / button sizemini bindtaponSend发送/button /view /view对应的 JS 逻辑// pages/chat/chat.js const app getApp() Page({ data: { msgList: [], draft: , scrollIntoId: , page: 1, hasMore: true, }, // 页面加载时拉历史消息并建立 WebSocket onLoad(options) { this.roomId options.roomId this.initRoom() }, async initRoom() { // 1. 先拉历史消息保证进房间能看到之前的内容 const historyRes await app.request({ url: /api/room/history, data: { roomId: this.roomId, page: this.data.page, }, }) this.setData({ msgList: historyRes.data.list, scrollIntoId: msg-${historyRes.data.list[historyRes.data.list.length - 1].msgId}, }) // 2. 建立 WebSocket 连接token 带在 URL 上做鉴权 const token wx.getStorageSync(token) this.ws wx.connectSocket({ url: ws://localhost:3000/ws?token${token}roomId${this.roomId}, }) this.ws.onMessage((res) { const data JSON.parse(res.data) if (data.type new_msg) { // 收到新消息追加到列表 const newMsg data.data this.setData({ msgList: [...this.data.msgList, newMsg], scrollIntoId: msg-${newMsg.msgId}, }) } }) }, onInput(e) { this.setData({ draft: e.detail.value }) }, onSend() { const content this.data.draft.trim() if (!content) return // 生成客户端消息 ID格式时间戳 随机数 const msgId ${Date.now()}_${Math.floor(Math.random() * 10000)} const tempMsg { msgId, senderRole: wx.getStorageSync(role), senderName: wx.getStorageSync(nickname), content, } // 先本地追加再通过 WebSocket 发给后端 this.setData({ msgList: [...this.data.msgList, tempMsg], draft: , scrollIntoId: msg-${msgId}, }) this.ws.send({ data: JSON.stringify({ type: send_msg, data: { msgId, content }, }), }) }, onLoadMore() { if (!this.data.hasMore) return // 分页加载更早的消息逻辑略 }, })这段代码里最关键的设计是「先本地追加再发 WebSocket」也就是乐观更新。用户点发送后消息立刻出现在列表里不用等服务端回包体感上流畅很多。但乐观更新有个副作用如果消息发送失败本地已经显示了需要在收到服务端失败回执时把这条消息标记为发送失败并允许用户点击重发。这个失败重发逻辑会牵扯到幂等后面避坑章节专门说。scroll-into-view是滚动定位的关键它的值必须是一个 DOM 元素的id。消息列表里每条消息都用idmsg-{{item.msgId}}包了一层新消息到达时把scrollIntoId更新成最新消息的id滚动视图就会自动滑到底部。这个方案在消息量少的时候没问题但消息超过几十条后每次都精确滚动还是会有一点点卡顿优化手段是「接近底部才滚动用户往上翻看历史时不强制拉到底部」。还有一个新手经常犯的错scroll-view必须设置明确高度不能靠内容撑开。常见做法是给scroll-view加flex: 1并让父容器占满页面或者直接写height: calc(100vh - 输入区域高度)否则scroll-into-view完全不生效。3.3 敏感词与快捷回复把咨询业务规则真正写进前端普通聊天室到上一步已经能用了但心理咨询聊天室必须有这两块业务功能敏感词预警和导师快捷回复。敏感词不能只靠后端过滤前端也要先拦一道目的是在消息上屏之前就给出提示避免敏感内容直接出现在聊天记录里。前端过滤的实现很简单维护一份敏感词数组发送前遍历匹配// utils/sensitive.js const sensitiveWords [不想活, 自杀, 抑郁, 坚持不住] // 示意数据 export function checkSensitive(content) { const hit sensitiveWords.find((word) content.includes(word)) if (hit) { return { level: 2, // 1 普通提醒2 紧急预警 word: hit, tip: 你当前的内容触发了情绪预警建议联系值班导师。, } } return null }在onSend里加上这个检查命中时弹窗提示并让用户确认是否仍要发送同时给消息打上「预警」标记后端收到后也会做一个二次过滤并推送给导师端。注意前端过滤只是一种体验优化不能替代后端过滤因为前端代码可以被绕过后端必须有一份完整的敏感词表和审核逻辑兜底。快捷回复是给导师用的功能。导师同时接待多个来访者时打字速度跟不上所以聊天页预设几条常用回复比如「我在的你慢慢说」「能具体描述一下最近的情况吗」「听起来你最近压力很大愿意多说一点吗」。实现上就是一个picker组件选中后自动填入输入框。这个小功能代码量不大但答辩时能体现出你对咨询业务的理解。4. 后端服务与业务闭环让聊天室从「能聊天」到「可交付」4.1 后端骨架HTTP 接口与 WebSocket 共用一个端口后端服务我习惯用 Node.js 来实现核心依赖只有两个一个 HTTP 框架处理普通接口一个 WebSocket 库处理长连接。这里有一个工程技巧把 HTTP 服务和 WebSocket 服务挂到同一个端口上这样小程序端只需要配一个域名或 IP不用区分 HTTP 和 WS 两个地址部署和答辩演示都省心。核心骨架代码// server/app.js const http require(http) const Koa require(koa) const Router require(koa/router) const { WebSocketServer } require(ws) const app new Koa() const router new Router() // 普通 HTTP 接口登录、拉历史、敏感词审核 router.post(/api/login, async (ctx) { // 登录逻辑换 openid、创建或查找用户、返回 token ctx.body { code: 0, data: { token: xxx, nickname: 同学A017, role: 1 } } }) router.get(/api/room/history, async (ctx) { // 分页查询历史消息 }) router.post(/api/room/create, async (ctx) { // 来访者发起新咨询创建房间 }) // 创建 HTTP 服务 const server http.createServer(app.callback()) // 把 WebSocket 服务挂到同一个 server 上 const wss new WebSocketServer({ server, path: /ws }) wss.on(connection, (ws, req) { // 从 URL 参数里拿 token 和 roomId做鉴权和房间绑定 const url new URL(req.url, http://localhost) const token url.searchParams.get(token) const roomId url.searchParams.get(roomId) // 校验 token无效则直接关闭连接 }) server.listen(3000, () { console.log(服务已启动: http://localhost:3000) })这个骨架有两个值得在答辩时讲清楚的设计点。第一WebSocket 的握手请求和普通 HTTP 请求一样会带上 URL所以 token 可以直接放在查询参数里服务端在connection事件里做鉴权鉴权失败就ws.close()避免未登录用户建立长连接。第二path: /ws让 WebSocket 只处理/ws路径的握手普通接口走router两者互不干扰。刚才小程序端连接地址是ws://localhost:3000/ws?tokenxxxroomIdxxx和这里是对应的。4.2 消息链路先写库、再广播、后确认的一小时闭环消息收发是聊天室后端最核心的链路顺序错了就会出现「消息丢了」或「消息重复」。我采用的顺序是收到消息 → 写数据库 → 广播给房间内所有连接 → 给发送者回执。先写库再广播这样就算广播环节出问题消息也已经落了库重连后拉历史记录不会丢数据。服务端消息处理代码// server/ws-handler.js const db require(./db) async function handleSendMessage(ws, payload) { const { msgId, content } payload.data const { roomId, userId } ws.context // 1. 幂等检查如果 msgId 已存在直接返回成功不重复入库 const exists await db.query(SELECT msg_id FROM messages WHERE msg_id ?, [msgId]) if (exists.length 0) { ws.send(JSON.stringify({ type: send_ack, data: { msgId, status: duplicate } })) return } // 2. 敏感词二次过滤命中则标记预警状态 const auditResult await checkSensitiveInDb(content) // 3. 写入数据库 await db.query( INSERT INTO messages (msg_id, room_id, sender_role, sender_name, content, is_audited) VALUES (?, ?, ?, ?, ?, ?), [msgId, roomId, ws.context.senderRole, ws.context.nickname, content, auditResult ? 2 : 1] ) // 4. 广播给房间内所有在线连接 const msg { msgId, roomId, senderRole: ws.context.senderRole, senderName: ws.context.nickname, content, isAudited: auditResult ? 2 : 1, createTime: new Date().toISOString(), } broadcastToRoom(roomId, JSON.stringify({ type: new_msg, data: msg })) // 5. 给发送者回执 ws.send(JSON.stringify({ type: send_ack, data: { msgId, status: ok } })) }这里最容易被忽略的是第 1 步幂等检查。如果没有这一步前端在弱网环境重发同一条消息相同的msgId后端会写入两条完全一样的内容用户就会看到「消息重复出现」。有了msg_id唯一索引和先查后插的逻辑重复消息会被拦截这是聊天室类项目必须有的基本功。另一个重点是消息顺序。WebSocket 消息到达服务端的顺序不等于用户发送的顺序所以前端展示时不能依赖数组push的顺序。我的做法是消息列表渲染前按createTime排序同时每条消息在客户端生成时带上时间戳服务端在入库时以服务器时间为准覆盖。如果两条消息同一秒到达再按msgId的字典序排保证顺序稳定。4.3 预约与评价两个给答辩加分的增量功能聊天室做到这里已经是一个完整可交付的项目了但如果想让答辩有更多亮点我建议再加两个小功能预约咨询和咨询评价。它们单独看都不复杂但合在一起能让评审老师觉得你想到了咨询业务的完整闭环。预约功能的实现思路是来访者在房间列表页或单独的预约页选择一个时间段提交预约值班导师端能看到待确认的预约确认后系统创建一个咨询房间到时间后双方从小程序进入房间开始聊天。数据库需要一个预约表字段包括预约 ID、来访者 ID、导师 ID、预约时间、状态待确认/已确认/已完成。评价功能更简单咨询结束后来访者对本次咨询打分并写一段文字反馈存评价表导师端可以看到自己的历史评价但看不到是谁评价的——匿名性在评价环节也要保持。这两个功能加起来大约多写两个页面、三个接口、两张表工作量可控但项目的故事线就完整了发现需求 → 预约 → 匿名咨询 → 结束评价这是学校心理咨询真实的服务流程。答辩时你把这条链路讲清楚老师很难再问出「你这个和普通聊天室有什么区别」这种问题。预约功能还有一个小坑如果导师不在线预约谁来确认我的处理是预约提交后进入待确认状态同时给导师端发一条订阅消息提醒导师下次打开小程序时能看到待办列表。订阅消息是微信小程序的一次性模板能力用户授权一次才能推一次不能当成常驻通知用这个限制后面避坑章节会再提到。5. 避坑指南毕业设计聊天室最常见的五种翻车现场5.1 真机显示白屏开发者工具里却一切正常现象在小程序开发者工具里预览、调试都正常一拿手机扫码预览页面直接白屏控制台也没有明显报错。原因最常见的是基础库版本不一致。开发者工具默认使用较高版本的基础库而手机上的微信如果版本较旧可能不支持你在代码里使用的某些新 API 或语法特性。另一个常见原因是代码里使用了 ES6 语法而「增强编译」选项没有打开导致真机环境无法解析。解决打开开发者工具的「详情 → 本地设置」勾选「将 JS 编译成 ES5」在项目配置里把基础库最低版本设低一些真机调试时先看手机端 vConsole 的报错信息不要只看开发者工具的控制台。经验是先在真机预览一遍再继续写后面的功能不要攒到最后一次性测那样翻车了都不知道是哪一步引入的问题。5.2 聊天记录超过 100 条后明显卡顿现象刚进房间时滑动流畅聊天记录越拉越多滑动开始掉帧输入文字也有延迟感。原因这是setData的典型问题。小程序每次setData都会把数据从逻辑层传到渲染层数据量越大传输越慢。聊天页如果每次追加消息都把整个msgList数组传一遍消息一多自然卡。解决两个手段配合。第一历史消息分页加载每次只加载 20 条scroll-view滚动到顶部时触发加载上一页而不是一次性把所有历史消息塞进数组。第二新消息到达时做局部更新setData只传新增的那一条不传全量数组。如果消息列表实在很长还可以考虑把超过一定数量的旧消息从数组里摘除只保留最近 200 条在内存中需要查看更早的再从服务端拉取。聊天记录越积越多的项目这条是必踩的坑。5.3 切后台再回来WebSocket 静默断开收不到消息现象用户正聊着天切到别的应用或锁屏过几分钟回到小程序发现消息收不到了界面看起来还停在原地发消息也没反应。原因微信小程序在进入后台一段时间后WebSocket 连接会被系统主动断开这是平台限制。更麻烦的是这个断开没有明确的事件通知前端还认为连接是通的继续发消息就一直失败。解决方案是「心跳探测 断线重连 补偿拉取」。前端每 30 秒发一个ping服务端回pong如果前端连续两次没有收到pong就主动销毁连接并重新建立。重新连接成功后不能只靠 WebSocket 补消息还要调一次/api/room/history接口带上本地最后一条消息的时间戳把离线期间漏掉的消息一次性拉回来。这个「断开后拉补偿」的链路答辩时被追问的概率极高建议重点准备。5.4 弱网环境消息重复入库聊天记录出现两条相同内容现象网络信号不好时点击发送界面提示发送失败用户重试了一次结果聊天记录里出现两条一模一样的内容。原因前端在发送失败后重试时为每条重试消息生成了新的msgId后端的幂等判断失效两条内容都入库了。本质是重试机制没有复用原始消息 ID。解决重试时复用原来那条消息的msgId服务端的幂等检查才能生效。我一般在onSend时就生成msgId并保存在消息对象里发送失败后重试直接取原msgId不重新生成。后端再加一层保险messages表的msg_id字段建唯一索引就算前端写错了数据库也会拦下重复插入。这一条不仅聊天室适用所有涉及「发送 确认 重试」的功能都该这么做。5.5 导师端收不到新消息提醒来访者白等半天现象来访者在聊天室发了一条消息导师手机锁屏或小程序在后台没有任何提醒来访者等了几分钟没回应体验很糟糕。原因小程序退到后台后 WebSocket 连接已断开消息推送根本到不了导师端。想用订阅消息解决但微信规定订阅消息是「一次性」的用户授权一次只能推一条不能像 APP 推送那样持续收到所以订阅消息只能做「触发式提醒」不能做常驻推送。解决在导师端做一层「在线状态 轮询兜底」。导师打开小程序时建立 WebSocket 并上报在线如果导师长时间没有交互后端在收到新消息时给导师端发一条订阅消息提醒「有新的咨询消息请打开小程序查看」。订阅消息的授权时机很关键要在导师首次使用 App 时用明确的弹窗请用户同意授权这个弹窗在毕设演示时要提前准备好免得现场演示时被系统弹窗打断流程。这套方案不算完美但在微信小程序的能力范围内已经是能落地的最优解。6. 演示录像怎么录让答辩老师三分钟看懂你的源码价值演示录像这个交付物很多同学都是随手拿手机对着屏幕录一遍操作就交了这是最亏的做法。录像其实是你的第二份「答辩陈述」录得好能大幅降低老师追问的密度。我的录法是三段式脚本每段都有明确目的总时长控制在 6 到 8 分钟。第一段是功能演示控制在 3 分钟以内。按真实用户路径走一遍来访者登录拿到匿名代号 → 进入房间发起咨询 → 导师端收到提醒进入房间 → 双方对话 → 触发一条敏感词看预警效果 → 结束咨询后评价。这里不要只演示「能聊天」要把咨询场景特有的流程演示到特别是匿名代号和敏感词预警这两个是普通聊天室没有的差异点。第二段是代码导读控制在 2 分钟。不用逐行讲用编辑器的文件树展示项目结构然后打开三个关键文件聊天页的 JS讲乐观更新和scroll-into-view、后端消息处理讲先写库再广播和幂等检查、数据库表结构讲msg_id和is_audited的设计意图。每处停留 20 秒左右告诉老师「这个文件里我做了一个 xx 处理解决的是 xx 问题」比对着屏幕滚动代码强十倍。第三段是异常演示控制在 1 分钟。把开发者工具的网络面板打开模拟离线状态发一条消息触发重试恢复网络后展示消息不重复、不丢失。再演示一次切后台再回来的断线重连补偿拉取。这两段是「加分演示」不是所有同学都会录录了就能让老师看到你是真的在真机环境下调试过而不是只在模拟器里点了两下。录制工具我用的是系统录屏录像分辨率调成 1080p帧率 30文件不要压缩得太狠保证文字清楚。再加上一条个人经验录像前先完整走一遍脚本把鼠标移动、键盘输入这些操作练顺录的时候不小心点错了一步就重录一遍一条 8 分钟的成品录像耗时小半天很正常写好脚本能少折腾很多次。我当时就是把脚本写在备忘录里每段干完打个勾整个录制过程不慌不忙。这套录法配合前面几章的代码结构你的毕设材料就齐了能跑通的小程序、结构清晰的后端、讲得清楚的设计决策和数据库字段外加一段一眼能看到亮点的演示录像。做这个项目最大的心得是聊天室的价值不在聊天本身而在于那些「为了让聊天在咨询场景下真正可信」而补上的细节——匿名、审核、幂等、断线补偿你能把它们讲成自己的故事这个毕设就算立住了。希望帮到你。本文还有配套的精品资源点击获取