微信小程序远程在线诊疗系统：基于SSM的完整设计与实现

简介面向高校毕业设计场景的微信小程序远程在线诊疗系统完整项目后端采用Java SSM框架与MySQL数据库前端为微信开发者工具构建的小程序并辅以Vue相关后台管理界面。系统内设管理员、用户、医生三类角色覆盖科室信息管理、预约挂号、取消预约、问诊与回复、患者信息管理、处方信息、通知公告、留言板等核心功能形成较完整的在线诊疗业务闭环。资源包共1417个文件总大小约39.85MB文件类型以Java源码、Vue组件、wxml/wxss/js小程序页面、JSON配置及PNG/JPG图片为主同时包含SQL数据库脚本以及开题报告、论文、PPT、使用说明等文档还附带bat一键安装与运行脚本便于部署和二次开发。目前已有57人下载学习适合计算机专业学生用于毕业设计参考、SSM与小程序全栈开发练习或快速搭建可演示的诊疗系统项目。1. 需求与可行性分析为什么远程在线诊疗系统必须做小程序端微信小程序远程在线诊疗系统这个题目的核心矛盾不在诊疗而在触达。很多学生拿到题目第一反应是做一个网页版管理后台等做出来才发现用户根本不用预约问诊的场景全在手机上让患者打开浏览器输网址、注册账号再预约流程还没走完就流失了。小程序端恰好把使用门槛降到最低——患者扫一下码就进去医生在手机上处理问诊管理员在后台管数据三条业务线都盘活了。这套方案适合正在做Java毕业设计的学生和想了解小程序与SSM后端如何对接的开发者覆盖管理员、用户、医生三个角色的完整流程。2. 总体架构设计SSM后端、MySQL与小程序前端的三层职责划分远程在线诊疗系统不是一个单端应用它至少要承担三条业务线用户在小程序里预约挂号、发起问诊医生在管理端查看问诊、写回复、生成处方管理员统一维护科室、公告、患者数据。如果一上来就写代码很容易把这三条线搅在一起。我一般先把系统拆成前端展示层、后端服务层、数据存储层去看每层职责划清楚后面实现才有章法。2.1 技术选型毕设场景下为什么用SSM而不是Spring Boot后台服务端选择 Java 的 SSM 框架Spring SpringMVC MyBatis是这套方案里最容易被质疑的选择。现在Spring Boot几乎是Java Web默认选项但在这个项目里仍然建议用SSM原因有三点第一SSM的配置是显式的Spring的Bean注入、SpringMVC的拦截器、MyBatis的Mapper映射都需要手动配反而不怕答辩时导师问“框架怎么工作的”因为你每一步都看得见第二课程和实验环境大量沿用SSM换Spring Boot意味着配套的参考代码和实验手册都要重新对齐时间成本翻倍第三SSM在本地用Tomcat就能跑不需要Spring Boot内置容器那套自动装配逻辑调试起来更直接。SpringMVC负责路由分发把小程序端发来的/api/doctor/list这类请求映射到对应ControllerSpring负责业务对象的依赖注入和事务管理MyBatis负责SQL与Java对象的映射。三层各管一段和系统本身的“展示-服务-存储”分层天然对应出了问题也能按层排查。本地开发时Tomcat监听8080端口MySQL监听3306小程序端在开发者工具里通过http://localhost:8080访问后端。这三个端口的关系理解清楚后面调跨域和域名校验就不会懵。2.2 三个角色的功能边界与权限控制系统里一共三类账号管理员、医生、用户三者的功能边界必须先从数据上划开。管理员对应后台管理端功能集中在“管理”两个字上用户管理、医生管理、科室类型管理、科室信息管理、患者信息管理、通知公告管理、医院介绍管理、留言板管理、系统管理外加个人中心。这套权限是典型的主数据维护场景管理端的Vue页面围绕这些模块做增删改查。医生对应的是接诊工作台功能是科室信息管理、预约挂号管理、取消预约管理、用户问诊管理、问诊回复管理、患者信息管理、处方信息管理。注意这里容易忽略的点医生也能看到科室信息但和管理员视角不同。医生看的是自己所在科室的号源和患者情况管理员看的是全部科室的配置数据前端是同一个页面后端查询条件不一样。用户对应小程序端核心操作就两件事对医生进行预约问诊操作和收藏操作。预约问诊是一个长流程用户要选科室、选医生、选时间、填患者信息、提交预约、等医生回复收藏则是一个轻操作在医生列表或医生详情页点一下星标。权限控制在SSM里怎么落地最朴素的方案是拦截器。我建议在SpringMVC的拦截器里做登录态校验公开接口放行其余接口在preHandle里从Session取登录信息取不到就返回统一未登录JSON。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri request.getRequestURI(); // 公开接口放行登录、科室列表、医院介绍 if (uri.startsWith(/api/auth/) || uri.startsWith(/api/public/)) { return true; } Object loginUser request.getSession().getAttribute(loginUser); if (loginUser null) { response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\请先登录\}); return false; } request.setAttribute(loginUser, loginUser); return true; } }这段拦截器是后端接口的第一道闸门。/api/auth/前缀下的登录注册接口不能拦否则用户永远进不来/api/public/下的科室列表和医院介绍要允许未登录状态浏览。这两个放行前缀写漏一个小程序打开就是一片空白或者登录死循环。拦截器只解决“是否登录”不解决“角色是否匹配”。严格区分管理员和医生可以在Controller里通过当前登录用户类型做二次判断不要让拦截器承担太多职责否则权限逻辑越改越乱。2.3 前端页面与后端接口的对应关系小程序端、Vue管理端、Java后端通过JSON接口通信。理解接口分组等于理解项目骨架。核心接口分组见下表这个映射可以直接用到接口设计文档里。模块后端接口前缀请求方典型功能认证/api/auth小程序微信登录、退出科室/api/department小程序科室列表、科室详情医生/api/doctor小程序医生列表、医生详情预约/api/appointment小程序医生端创建预约、取消预约、预约列表问诊/api/consultation小程序医生端发起问诊、回复问诊处方/api/prescription医生端生成处方、处方列表管理/api/manageVue管理端用户管理、公告管理、留言板注意“请求方”这一列。同一个预约接口小程序端和医生端都会调但参数不一样小程序创建预约传doctorId、patientName、appointmentDate医生端查预约列表传当前登录医生的doctorId。接口文档里把这两个场景分开写联调时就不容易扯皮。提示写接口文档的习惯可以从这个项目开始养成。一张表列出接口地址、入参、出参、访问角色后端照着写Controller前端照着写页面开发到一半也不会冒出“我不知道你传了什么字段”的沟通成本。3. 数据库设计核心表结构与预约状态机的落地远程在线诊疗系统的表结构第一眼看上去多但拆开只有三类账号类、业务类、内容类。账号类给三类角色提供登录基础业务类负责预约、问诊、处方核心流程内容类负责科室、公告、医院介绍这类展示数据。设计表时不要追求数量多要保证每张表都能在业务流程里找到存在意义。3.1 账号类表user、doctor、admin 的字段设计用户表、医生表、管理员表建议拆成三张独立表而不是共用一张user表加role字段。共用表意味着大量if (role 1)分支判断业务一复杂代码就发臭。user表核心字段id主键、username登录名、password加密存储、realName真实姓名、phone手机号、avatar头像、gender性别、createTime注册时间。password只在登录注册两个场景用到Controller里绝对不能把password对象序列化返回给前端。doctor表要体现医患关系的特殊性doctorName、departmentId所属科室外键、title职称、introduction个人简介、workTime出诊时间、maxAppointments排班号源上限、status在职状态1在职0停诊。admin表最简单id、username、password、realName、createTime。三张表设计完第一个要确认的外键约束是doctor表的departmentId关联科室表。建表时加外键约束同时建普通索引因为按科室查医生是高频查询没有索引数据量一大就慢。3.2 业务类表预约、取消预约、问诊、处方预约挂号表是状态变化最复杂的表。字段至少包括id、appointmentNo预约单号、userId预约人、doctorId接诊医生、departmentId科室冗余字段、patientName就诊人姓名、patientPhone就诊人电话、appointmentDate预约日期、timeSlot时间段、status0待就诊1已就诊2已取消、createTime、cancelTime。这里特意保留departmentId冗余字段用户在小程序端看到“科室-医生”两级联动但预约记录查出来后列表页要同时展示科室名和医生名。只存doctorId每次查询都得JOIN两次冗余一个departmentId能减少一次关联查询。编码规范上还要注意一点patientName和patientPhone属于快照字段预约发生时直接存一份患者后续改资料不影响历史预约单这在医疗场景必须保证。取消预约表独立成表是有意为之业务上要记录“谁在什么时间取消了哪个预约”。字段为id、appointmentId、userId、doctorId、cancelReason、cancelTime。问诊表围绕“用户发起问诊-医生回复”链路设计id、userId、doctorId、consultationContent问诊描述、consultationStatus0待回复1已回复、createTime、replyTime。问诊回复表单独保存回复内容id、consultationId、doctorId、replyContent、replyTime、prescriptionId关联处方。处方信息表要能支持医生生成一张简单电子处方id、appointmentId、userId、doctorId、diagnosis诊断结果、drugList药品列表JSON格式或逗号分隔文本、amount费用、createTime。毕设阶段药品列表用逗号分隔字符串完全可以接受不要为边角需求引入药品主数据表反而增加画E-R图的负担。3.3 内容类表与状态流转设计科室类型表和科室信息表是两级结构容易犯迷糊的是把这两个表合成一张。科室类型表是分类维度内科、外科、儿科科室信息表是具体科室心血管内科、消化内科、普通外科。department_type字段为id、typeName、createTimedepartment字段为id、typeId关联科室类型、deptName、deptDesc、createTime。用户问诊状态流转是待回复 → 已回复医生对问诊生成处方时在回复表里记录prescriptionId形成问诊和处方的关联。预约状态是比较危险的一段用户发起预约status0有效期内主动取消status2按时就诊、由医生端标记“已就诊”status1。关键约束是已取消的记录不允许重新置回待就诊状态医生端做状态更新必须在SQL里加上状态条件。-- 加上状态条件防止已取消的预约被覆盖为已就诊 UPDATE appointment SET status 1 WHERE id #{appointmentId} AND status 0;这条SQL携带AND status 0条件是防止“已取消预约被医生误标记为已就诊”的关键。如果更新不带状态判断先有请求把状态改成已取消随后医生端请求就会把它覆盖成已就诊带条件更新受影响行数为0时后端可以通过返回值提示前端“预约不存在或已被取消”。3.4 数据库初始化脚本的组织方式项目根目录的1-install.bat到3-build.bat对应三个阶段安装依赖、启动服务、构建前端。数据库初始化脚本放在sql/目录下用init.sql建表、data.sql插基础数据。管理员默认账号、科室类型、医院介绍这些内容都预置在data.sql里。这样组织的好处是拿到项目的人按脚本顺序执行不需要手敲一条SQL。答辩演示现场如果数据库是全新库跑一遍初始化脚本就能把整个系统从零拉到可演示状态。4. 关键模块实现从微信授权登录到处方生成的完整链路设计图和数据库表都有了这一章落到代码层面把系统里最核心的三条链路走通用户在小程序端发起预约、医生在管理端回复问诊并生成处方、管理员在后台维护基础数据。写代码之前先明确工程背景这是一个Eclipse Java Web工程.classpath和org.eclipse.wst.common.component文件决定了IDE按标准Web工程识别配合Tomcat部署运行。4.1 微信授权登录的后端实现微信小程序的登录不能用传统用户名密码流程是小程序调用wx.login()拿临时code传给后端后端拿code加上appid和secret去微信接口换openid再用openid查user表查不到就自动注册。RestController RequestMapping(/api/auth) public class AuthController { PostMapping(/wxLogin) public Result wxLogin(RequestBody MapString, String params) { String code params.get(code); String nickname params.get(nickname); String avatar params.get(avatar); String openid wxService.getOpenId(code); if (openid null) { return Result.error(微信登录失败code已过期或无效); } User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setUsername(user_ System.currentTimeMillis()); user.setNickname(nickname); user.setAvatar(avatar); userMapper.insert(user); } session.setAttribute(loginUser, user); return Result.success(user); } }这段代码的关键在wxService.getOpenId(code)它内部封装了微信code2Session接口的调用用HttpClient把code、appid、secret拼成GET请求发出去解析返回JSON里的openid。注意不能把appid和secret暴露在小程序端这两个值必须放在后端配置里。开发阶段最常见的翻车点是小程序请求后端报错fail url not in domain list。后端跑在本地8080端口微信请求域名校验默认开着直接请求localhost肯定被拦。注意开发阶段在微信开发者工具的“详情-本地设置”勾选“不校验合法域名”即可但上线前必须配置合法request域名并改用HTTPS。第一次跑通登录接口建议把返回JSON打印出来看一眼。确认openid真的换到了且新用户自动落到了user表。实际开发里出现过前端说“调了登录但进不了系统”最后发现是微信接口返回了报错JSON代码里没做异常处理把null当成成功返回。4.2 预约挂号接口与账号并发保护预约模块核心接口三个创建预约、取消预约、查询预约列表。创建预约为重点因为每个医生排班号源有上限要防止两个用户几乎同时把最后一个号抢走。Transactional public Result createAppointment(Appointment appointment) { Doctor doctor doctorMapper.selectById(appointment.getDoctorId()); // 统计该医生当天的已预约数量 Integer count appointmentMapper.countByDoctorAndDate( appointment.getDoctorId(), appointment.getAppointmentDate()); if (count doctor.getMaxAppointments()) { return Result.error(该医生当天号源已满请选择其他时间); } appointment.setStatus(0); appointment.setAppointmentNo(generateNo(doctor.getId())); appointmentMapper.insert(appointment); return Result.success(预约成功); }这段逻辑单用户测试没问题但仔细看是“查-判-写”三步两个请求同时查出count9上限10两个都通过判断都执行插入实际预约数变成11超卖一个号。这是答辩时容易被追问到的并发问题。解决策略有两个层次最简单是把“判满”和“写入”合并成一条带条件的更新语句在doctor表增加appointCount字段保存当天已预约数每次预约先执行UPDATE doctor SET appoint_count appoint_count 1 WHERE id #{doctorId} AND appoint_count #{maxAppointments}受影响行数为0就返回满号更稳妥的是在appointment表建联合唯一约束用(doctorId, appointmentDate, timeSlot)做联合唯一索引数据库层面拒绝重复预约。两者结合最稳答辩时讲清楚一种就够。取消预约相对简单把预约记录status置为2同时往取消预约表插一条审计记录。注意操作顺序先插取消记录再改预约状态两个操作放进一个事务任何一个失败整体回滚避免出现“取消了但没记下来”的中间状态。4.3 问诊回复与处方生成的交互逻辑问诊链路是“用户发起→医生回复→生成处方”三段式。用户在小程序端提交问诊描述生成一条consultation记录status为0医生端看到待回复列表点开详情写回复如果涉及开药在回复页连带生成一张处方。设计时注意页面跳转传参小程序里从医生列表进入问诊详情携带的doctorId建议放在页面实例data里不要在跳转URL里用一长串参数。医生提交回复时前端表单校验要保证回复内容和处方药品不为空才允许提交否则用户收到一条空回复体验很差。医生端生成处方后问诊状态由0变为1回复表记录prescriptionId关联。这一步的状态更新同样建议带条件SQLUPDATE consultation SET status 1, reply_time #{time} WHERE id #{id} AND status 0防止医生重复提交导致状态被覆盖。4.4 小程序端预约与收藏的页面交互实现用户端核心交互两个预约和收藏。预约页面从医生详情进入展示医生信息、出诊时段和剩余号源日期时段由后端返回的号源列表驱动前端写死时段列表会导致医生修改排班后页面不同步。已约满的时段按钮置灰。收藏按钮进页面时要先查当前用户是否已收藏该医生已收藏高亮未收藏灰态。点击时先更新本地状态再调接口失败回滚。// 小程序端预约提交 submitAppointment() { const { doctorId, patientName, patientPhone, date, timeSlot } this.data; wx.request({ url: http://localhost:8080/api/appointment/create, method: POST, data: { doctorId, patientName, patientPhone, appointmentDate: date, timeSlot }, header: { Content-Type: application/json }, success: (res) { if (res.data.code 0) { wx.showToast({ title: 预约成功, icon: success }); this.setData({ submitted: true }); } else { wx.showToast({ title: res.data.msg, icon: none }); } }, fail: () { wx.showToast({ title: 网络异常请重试, icon: none }); } }); }注意代码里写的是http://localhost:8080这在开发者工具里能跑通但真机预览时访问不到电脑的localhost。真机测试要么把地址改成电脑在局域网内的IPhttp://192.168.x.x:8080要么部署到带HTTPS证书的服务器。建议从一开始就维护一个config.js把baseUrl集中写成常量换环境只改一处这是小程序调试第一大坑。5. 常见问题排查与避坑指南从404到数据覆盖的五个高频事故这套系统最值钱的经验都在排错里。从本地运行、联调、答辩演示三个场景里挑几个高频翻车点按“现象→原因→解决”讲比背十遍框架原理都管用。5.1 小程序请求后端报错fail url not in domain list现象小程序端所有请求失败控制台报错有“url not in domain list”字样页面白屏。原因微信开发者工具的默认配置会校验request合法域名后端跑在本地8080端口不在任何合法域名列表里。解决开发阶段在微信开发者工具“详情-本地设置”勾选“不校验合法域名”。注意这个选项只影响开发者工具真机预览仍会被微信校验所以真机调试要么部署到HTTPS服务器要么一直用预览二维码而不是正式发布。5.2 后端接口404且Tomcat启动无报错现象浏览器访问http://localhost:8080/api/doctor/list返回404Tomcat正常启动没有抛异常。原因SSM项目这类404九成是SpringMVC没扫到Controller或DispatcherServlet的url-pattern配置不对。解决优先查三个位置SpringMVC配置文件里context:component-scan base-packagecom.xxx.controller/是否指向Controller所在包web.xml里DispatcherServlet的url-pattern是不是/配成/*会拦截JSP导致404MyBatis的Mapper接口是否被Spring容器扫描到扫不到会报“no bean named xxxMapper”。5.3 预约状态被覆盖已取消变成已就诊现象用户刚取消预约医生端随后点击“就诊完成”系统提示成功但记录状态变成已就诊。原因医生端更新状态SQL没携带状态条件直接UPDATE appointment SET status1 WHERE id#{id}先取消再改状态的顺序导致覆盖。解决把状态更新SQL改成带条件更新并检查受影响行数。这个坑也提醒前端同学所有状态变更操作后端不能只判断“有没有这条记录”还要判断“当前状态允不允许这么变”。5.4 把.bak文件误当成配置或启动文件现象项目解压后看到main.css.bak、update-password.vue.bak一堆文件以为是配置模板改了之后编译报错。原因.bak文件是开发过程中的备份文件不是运行必需的。.classpath和org.eclipse.wst.common.component是Eclipse工程描述文件IDE按这些文件识别项目类型。解决真正入口是1-install.bat、2-run.bat、3-build.bat顺序不能颠倒先安装依赖再启动服务再构建前端。1和3容易混淆安装是给项目装依赖构建是编译前端资源跳过构建直接用旧资源页面改动不会生效。5.5 管理员登录后刷新页面就掉线现象管理员在Vue管理端登录后切到下一个页面就提示未登录操作频繁时弹回登录页。原因管理员登录信息在Session里Vue管理端与后端交互时Axios默认没有携带CookieSessionId无法维持后端拿不到会话自然判断为未登录。解决前端Axios实例设置withCredentials: true后端响应跨域请求时设置Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin不能用*必须返回具体域名。两个条件都满足才能让Session跨域生效。这个坑建议项目一开始就配好别等演示当天发现。5.6 MySQL时区导致的日期时间错乱现象预约记录里的createTime比本地时间早8小时或者日期查询总是差一天。原因MySQL连接串没加serverTimezoneAsia/Shanghai驱动和系统时区不一致导致的日期V差错。解决JDBC连接串加上?serverTimezoneAsia/ShanghaiuseSSLfalse同时确认数据库本身时区为东八区。这个问题在本地环境偶尔不出现一换环境就暴露属于做完项目最后才发现的定式。6. 系统验收与答辩准备功能走查清单与十分钟演示脚本代码写完到交差之间还有一道关键工序验收。三角色项目不能只看“代码能跑”要按角色走完整业务流程打印一份功能走查清单跑一项勾一项。6.1 三角色验收走查清单角色主流程验收标准用户注册登录微信登录成功新用户自动建档用户浏览科室医生科室列表→医生列表→医生详情正常跳转用户预约挂号号源充足时可预约号满时提示用户取消预约取消后列表状态变为已取消用户发起问诊问诊创建成功状态为待回复用户收藏医生收藏列表可查取消收藏后消失医生登录后台跳转到医生工作台而非管理员页医生处理预约可将待就诊预约标记为已就诊医生回复问诊提交回复并生成处方状态变为已回复管理员登录后台看到全部管理模块菜单管理员用户医生管理可新增、停用、编辑账号管理员内容管理通知公告、医院介绍、留言板可增删改查走查时把所有用例的输入输出记录下来顺手截图存档。这部分截图贴在论文里就是功能测试章节的素材答辩时直接翻记录对应演示比自己临时在页面上点来点去的效果靠谱得多。6.2 十分钟演示脚本与答辩要点演示脚本按“用户端-医生端-管理员端”三段来排每段三分钟。开场先展示小程序用户端浏览科室、选医生、预约、发起问诊再切到医生端处理问诊、生成处方最后切到管理员端展示数据管理。这个顺序顺着业务流程走导师看起来不会因为频繁切换页面而混乱。答辩被追问概率最高的三个点为什么用SSM不用Spring Boot、数据库为什么这么设计、并发场景怎么处理。回答逻辑在前面章节都覆盖了SSM配置可见性适合教学场景、数据库设计遵循业务状态机加快照冗余、并发用条件更新加唯一索引兜底。回答时不要背书式陈述直接把小程序端、医生端各自的诉求串起来讲一遍业务链路处理过程。还有一个反直觉的建议如果答辩现场网络不好提前准备一份离线演示包。把开发者工具缓存数据、后端测试数据、数据库快照都准备好保证断网状态下前端能演示、后端有数据可查。从那以后我每次做带小程序的毕设项目都会强制把离线演示包写进验收清单宁可多准备也不现场翻车。希望这个方法也能帮到你的答辩。本文还有配套的精品资源点击获取