简介这是一套面向高校计算机相关专业毕业设计的微信小程序远程在线诊疗系统完整资料适合正在准备毕设、需要真实项目练手的同学参考。系统划分管理员、医生、用户三种角色管理员负责用户、医生、科室类型与信息、患者信息、通知公告、医院介绍、留言板及系统管理医生可处理预约挂号、取消预约、用户问诊与回复、患者信息及处方信息用户则能预约问诊并收藏医生业务闭环较为完整。压缩包共1417个文件约39.85MB涵盖151个java后端源码、153个vue管理端页面、208个js脚本、110个wxss与108个wxml小程序页面以及png、svg、jpg等界面素材和sql数据库脚本另附开题报告、论文、ppt与使用说明。后台基于Java SSM框架与MySQL开发小程序端使用微信开发者工具界面清晰、操作简单。已有56人学习可作为毕设选题、代码复现与文档撰写的参考模板。1. 从一份能跑起来的远程在线诊疗系统说起微信小程序 Java 到底解决了什么远程在线诊疗这件事真正难的不是把视频通话接进来而是让「患者建档—挂号—候诊—图文问诊—视频复诊—开方—处方流转—随访」这条链路在微信小程序里闭环并且后端能扛住医生排班、号源并发、消息推送和病历留痕。基于微信小程序的远程在线诊疗系统本质是一套「小程序端做触达、Java 后端做业务与合规、数据库做状态机」的三段式架构。它适合正在做 Java 毕业设计、课程设计或者想拿一套完整开源项目练手全栈的开发者小程序负责低门槛触达患者JavaSpring Boot 为主流选型负责诊疗业务编排MySQL 负责把每一次问诊、每一条处方都落成可追溯的记录。这一章先把「它是什么、能解决什么、谁适合做」讲清楚后面几章再拆开讲怎么落地、参数怎么设、坑在哪。2. 远程在线诊疗系统的技术选型为什么是微信小程序 Spring Boot MySQL2.1 小程序端为什么比 App 更适合诊疗入口诊疗系统的用户分两类患者和医生。患者端最怕的是「下载安装」这一步流失微信小程序扫码即用、授权即登录天然适合挂号、缴费、查报告这类低频但刚需的场景。医生端如果也放在小程序里好处是排班、接诊、开方能在手机上一气呵成不用再装一个独立 App。但小程序也有硬边界选型时必须提前认账能力小程序支持情况对诊疗系统的影响实时音视频需接入实时音视频组件非原生 WebRTC视频复诊要单独设计房间与鉴权后台保活不支持长时间后台运行候诊提醒必须靠订阅消息不能靠长连接本地存储单 key 上限约 1MB总量约 10MB病历、影像不能缓存在本地必须回源文件下载有临时文件与保存限制报告 PDF 建议后端生成后给短时链接所以常见做法是患者端、医生端都用小程序把重计算和重存储全部压到 Java 后端。小程序只做展示和交互业务状态一律以后端为准这样即使小程序被切后台问诊状态也不会丢。2.2 Java 后端的分层与核心模块划分后端我一般按「接入层—业务层—领域层—基础设施层」来切落到包结构大致是这样// 典型 Spring Boot 包结构按诊疗业务域拆分 com.clinic ├── controller // 小程序接口入口统一 /api/wx/** 前缀 │ ├── AuthController // 登录、绑定手机号 │ ├── AppointmentController // 挂号、号源、取消 │ ├── ConsultController // 图文/视频问诊会话 │ └── PrescriptionController// 开方、处方状态流转 ├── service // 业务编排事务边界在这一层 ├── domain // 实体与状态机如 ConsultSession、Prescription ├── mapper // MyBatis-Plus 数据访问 └── infra // 微信 SDK、短信、对象存储、消息推送封装逻辑说明controller 只做参数校验和鉴权不写业务service 负责把「挂号成功 → 生成候诊号 → 推送订阅消息」串成一个事务domain 里用枚举定义状态机避免状态散落在各处。参数上接口统一走/api/wx前缀方便网关做限流和日志切面。2.3 数据库表设计把问诊状态机落成字段数据库是整个系统的黑匣子状态设计错了后面全是血泪经验。核心表我一般这么建-- 问诊会话表一条记录代表一次完整问诊 CREATE TABLE consult_session ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL COMMENT 患者用户ID, doctor_id BIGINT NOT NULL COMMENT 医生ID, session_type TINYINT NOT NULL COMMENT 1图文 2视频, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待接诊 1进行中 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_doctor_status (doctor_id, status), INDEX idx_patient (patient_id) ) COMMENT 问诊会话;逻辑说明status用整型枚举而不是字符串索引效率更高idx_doctor_status支撑医生端「我的待接诊列表」这个高频查询。参数上session_type区分图文和视频因为两者的超时策略、消息通道完全不同混在一张表里但用字段区分比拆两张表更好维护。提示号源表一定要加唯一索引(doctor_id, schedule_date, time_slot)否则并发抢号必然超卖这是最常见的翻车点。3. 从零跑通最小闭环登录、挂号、问诊、开方四步落地3.1 小程序登录与手机号绑定的最小实现微信小程序的登录不是「账号密码」而是wx.login拿 code后端换 openid。这一步做错后面所有用户体系都是歪的。// 小程序端登录并换取后端 token wx.login({ success: (res) { // res.code 只能用一次5分钟内有效 wx.request({ url: https://your-domain/api/wx/auth/login, method: POST, data: { code: res.code }, success: (r) { // 后端返回自定义 token存本地用于后续鉴权 wx.setStorageSync(token, r.data.token); } }); } });逻辑说明code是一次性凭证后端拿它去微信服务端换openid和session_key绝不能把session_key下发到小程序。参数上后端应把openid与自建user_id做映射后续业务全部用user_id避免直接暴露openid。// 后端code 换 openid生成业务 token public String login(String code) { // 调用微信接口appid secret code WxSession session wxClient.code2Session(code); User user userMapper.selectByOpenid(session.getOpenid()); if (user null) { user new User(); user.setOpenid(session.getOpenid()); userMapper.insert(user); // 首次登录自动建档 } return jwtUtil.sign(user.getId()); // 只签业务ID }逻辑说明首次登录自动建档避免「先注册再登录」的多余步骤。参数上JWT 里只放user_id和过期时间角色患者/医生从数据库查防止 token 被篡改提权。3.2 号源并发控制把超卖挡在数据库层挂号是典型的秒杀场景医生号源有限并发一上来就超卖。我一般用「数据库唯一索引 乐观锁」双保险。-- 号源表唯一索引是防超卖的最后一道防线 CREATE TABLE doctor_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doctor_id BIGINT NOT NULL, schedule_date DATE NOT NULL, time_slot VARCHAR(16) NOT NULL COMMENT 如 09:00-09:30, total INT NOT NULL, booked INT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, UNIQUE KEY uk_slot (doctor_id, schedule_date, time_slot) ) COMMENT 医生排班号源;// 扣减号源乐观锁 影响行数判断 Transactional public void book(Long scheduleId) { DoctorSchedule s scheduleMapper.selectById(scheduleId); if (s.getBooked() s.getTotal()) { throw new BizException(号源已满); } int rows scheduleMapper.updateBooked(scheduleId, s.getVersion()); if (rows 0) { throw new BizException(手慢了请重试); // 版本冲突 } }逻辑说明updateBooked的 SQL 带WHERE version #{version} AND booked total影响行数为 0 说明被别人抢先直接让用户重试。参数上version每次更新自增booked total作为兜底条件即使乐观锁失效也不会超卖。3.3 图文问诊的消息落库与已读回执图文问诊的核心是消息表必须支持「谁发的、发给谁、是否已读」。CREATE TABLE consult_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id BIGINT NOT NULL, sender_id BIGINT NOT NULL, sender_role TINYINT NOT NULL COMMENT 1患者 2医生, content TEXT, msg_type TINYINT NOT NULL DEFAULT 1 COMMENT 1文本 2图片 3处方卡片, is_read TINYINT NOT NULL DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_session (session_id, create_time) ) COMMENT 问诊消息;逻辑说明idx_session支撑按会话拉取历史消息create_time保证顺序。参数上msg_type预留处方卡片类型医生开方后自动往会话里插一条卡片消息患者点开即可查看不用另做通知。3.4 开方与处方状态流转处方是诊疗系统里合规要求最高的部分状态必须严格单向流转。// 处方状态机草稿 - 已提交 - 已审核 - 已发药 public enum PrescriptionStatus { DRAFT(0), SUBMITTED(1), REVIEWED(2), DISPENSED(3); private final int code; PrescriptionStatus(int code) { this.code code; } public int getCode() { return code; } }逻辑说明用枚举固定状态任何跳步如草稿直接到已发药都在 service 层拦截。参数上每次状态变更写一条操作日志表记录操作人、时间、前后状态方便追溯。4. 远程在线诊疗系统的避坑清单五个真实踩过的坑4.1 坑一小程序订阅消息发不出去现象患者挂号成功但收不到候诊提醒。原因订阅消息需要用户主动授权且模板 ID 与后端配置不一致或者openid与template_id不匹配。解决在挂号按钮上先调wx.requestSubscribeMessage拿授权后端把template_id抽到配置中心发送前校验用户是否授权过未授权则降级为站内消息。4.2 坑二视频问诊房间鉴权被绕过现象有人拿到房间号就能进别人的问诊。原因房间号直接用了session_id没有做用户与房间的绑定校验。解决进房前必须调后端接口换取带签名的临时房间凭证凭证里绑定user_id和session_id有效期设 5 分钟过期重签。4.3 坑三数据库连接池被打满现象高峰期接口大面积超时日志显示获取连接超时。原因问诊消息查询没走索引慢 SQL 占住连接连接池最大连接数设得过小。解决给consult_message补索引连接池maximumPoolSize按「CPU 核数 × 2 磁盘数」估算同时加慢 SQL 监控超过 1 秒的查询打日志告警。4.4 坑四病历图片存本地导致迁移丢数据现象换服务器后历史病历图片全部 404。原因图片直接存到了应用服务器本地磁盘。解决统一走对象存储数据库只存 key读取时后端生成带签名的短时 URL。参数上签名 URL 有效期设 10 分钟避免被长期盗链。4.5 坑五医生排班时区与日期错位现象跨零点排班时号源日期对不上。原因schedule_date用了DATE但应用层用LocalDateTime转换时区不一致。解决排班日期统一用LocalDate数据库连接串显式指定时区前后端约定日期格式为yyyy-MM-dd不做隐式转换。5. 进阶技巧用状态机 定时任务把问诊超时自动化5.1 用定时任务扫描超时会话问诊最怕「医生一直不接诊患者干等」。我一般加一个定时任务扫描超过 15 分钟仍是「待接诊」的会话自动取消并退款。// 每 5 分钟扫描一次超时未接诊会话 Scheduled(cron 0 */5 * * * ?) public void cancelTimeoutSession() { // 查询 15 分钟前创建且状态为待接诊的会话 ListConsultSession list sessionMapper.selectTimeout( LocalDateTime.now().minusMinutes(15)); for (ConsultSession s : list) { s.setStatus(3); // 已取消 sessionMapper.updateById(s); refundService.refund(s.getId()); // 触发退款 } }逻辑说明cron表达式每 5 分钟执行一次扫描窗口 15 分钟避免频繁查询。参数上超时时间做成配置项不同科室可以设不同值比如急诊 5 分钟、普通门诊 15 分钟。5.2 状态机校验防止非法流转所有状态变更都走一个统一的校验方法避免各处乱改状态。// 状态流转校验只允许相邻状态跳转 public void transit(ConsultSession s, int target) { int current s.getStatus(); // 允许的流转0-1, 0-3, 1-2, 1-3 boolean ok (current 0 (target 1 || target 3)) || (current 1 (target 2 || target 3)); if (!ok) { throw new BizException(非法状态流转); } s.setStatus(target); sessionMapper.updateById(s); }逻辑说明把合法流转写成白名单任何不在白名单里的变更直接抛异常。参数上白名单随业务扩展维护新增状态时同步更新避免遗漏。5.3 验证方法用压测确认号源不超卖上线前一定要压测挂号接口。我一般用 JMeter 或 wrk 对/api/wx/appointment/book发 500 并发检查booked是否等于total且没有一条记录超过total。如果出现超卖先看唯一索引是否生效再看乐观锁的version条件是否写对。这一步做完心里才有底。我自己做这类系统最大的教训是别急着写业务代码先把状态机和表结构定死后面改状态的代价远大于改接口。数据库设计阶段多花两天能省掉上线后两周的救火。希望帮到你。本文还有配套的精品资源点击获取