1. 项目概述与选题思路这两年我带过的毕设小组里至少有一半人第一眼看到在线问诊系统这个题目时会觉得它不就是个增删改查吗。说实话这个判断对了一半——如果只想做一个能跑起来的 demo那确实就是一个带了权限控制的 CRUD但如果你愿意往深处走一层这个题目其实能挖出非常多值得写在简历上的东西比如多角色权限模型设计、问诊会话的状态机流转、支付与订单对账、消息推送的延迟与重试、甚至医生排班和号源锁定的并发问题。先说这个系统到底是干什么的。一句话概括它把一个线下医院的问诊流程搬到了 Web 端让患者可以在线找医生、提交病情描述、预约问诊时间医生可以接诊、查看病历、给出诊断建议和处方管理员负责审核医生资质、管理科室与药品信息、查看平台运营数据。整个系统里有三种基础角色患者、医生、管理员后期还能扩展药师、护士等辅助角色。从毕设选题的角度来看这个题目有几个天然优势。其一业务场景足够贴近生活答辩时评委不需要你解释半天你这个系统是干嘛的demo 演示直观其二技术覆盖面广既能体现 Java 基础集合、异常、多线程又能体现 Web 开发能力Servlet/Spring MVC、前端交互、会话管理还能体现数据库设计能力ER 建模、事务、索引一个题目把大学四年学的东西基本都串起来了其三后期可以随时加亮点功能比如接入了 WebSocket 实现医生与患者的实时对话或者用 Redis 做号源缓存或者用 RabbitMQ 做异步消息通知这些都是加分项。但我也要提前泼一盆冷水正因为这个题目常见答辩时老师见过的同类系统非常多如果你只是把别人的代码换个皮交上去很容易被问倒。真正能拿高分的做法是把多角色权限边界和问诊流程的完整闭环这两个核心点做扎实让老师感受到你是真的理解了业务而不是背了几个注解。2. 技术选型与项目结构设计2.1 后端框架怎么选才不会翻车先说框架。现在 2025 年还在用纯 JSP Servlet 写新项目的人确实不多了除非你们学校硬性要求不能用框架。如果让我推荐Spring Boot 是绝对的首选原因很简单它把以前 Spring MVC 项目里繁琐的 XML 配置全部约定化你只要引入几个 starter写一个启动类项目就能跑起来。而且毕设答辩时老师最关心的几个问题——依赖管理、自动配置、内嵌 Tomcat——都是 Spring Boot 的核心特性你天然就站在了一个能讲出东西的位置上。具体版本建议用 Spring Boot 2.7.x 或者 3.x看你自己 JDK 的版本。如果 JDK 是 8那就老老实实用 2.7.x别硬上 3.x因为 Spring Boot 3 要求 JDK 17 起步到时候环境变量折腾半天纯粹是给自己找麻烦。我见过不止一个学生因为版本不匹配在启动阶段就卡了一整天最后发现是 JDK 和 Spring Boot 的大版本对不上。MyBatis 和 MyBatis-Plus 怎么选我的建议是直接用 MyBatis-Plus。理由不是什么国产框架更友好而是它内置的 BaseMapper 能把你从重复的单表 CRUD 里解放出来让你把精力放在真正的业务逻辑上。更重要的是Plus 的分页插件真的很好用你写一个PageUser对象插件自动帮你拼 LIMIT 语句连 count 查询都帮你优化了。答辩时老师问你怎么做分页的你至少能答出物理分页和逻辑分页的区别——物理分页是数据库层面用 LIMIT 截断逻辑分页是查出全部数据后在内存里截取Plus 默认走物理分页性能更好。2.2 前端方案别在花里胡哨上浪费时间前端可能是很多 Java 选手最头疼的部分但我必须说一句毕设的前端真的不需要你做出花来。我见过有人用 Vue 3 Element Plus 搭了一套非常精致的管理后台结果时间全耗在前端样式上了后端逻辑反而写得稀烂答辩时被问得哑口无言——这就是典型的本末倒置。最稳妥的方案是后端用 Spring Boot 提供 JSON 接口前端用 Thymeleaf 模板引擎渲染页面结合 Bootstrap 或 Layui 做样式。为什么选 Thymeleaf因为它和 Spring Boot 无缝集成你只需要在pom.xml里加一个spring-boot-starter-thymeleaf依赖然后在application.properties里配一下前缀后缀路径页面里用th:each、th:if这些语法就能直接渲染后端传过来的数据。这比 Vue 少了跨域处理、前端路由、状态管理一堆麻烦事对于毕设来说完全够用。当然如果你觉得自己的前端能力还行也有多余的时间用 Vue 3 Element Plus 做一个前后端分离版本是可以加分的但前提是你必须把 token 认证、跨域配置、axios 封装这些东西讲清楚否则评委一眼就看出你是网上抄的模板。2.3 数据库设计在线问诊的核心是表关系数据库设计是整个系统里我最想强调的部分因为很多人的表结构一拿出来就知道是临时凑的——字段命名随意、主外键关系混乱、没有考虑索引。在线问诊系统最少需要这九张表用户表、医生信息表含科室和职称、科室表、患者信息表、问诊订单表、问诊记录表消息记录或诊断记录、处方表含药品明细、药品表、管理员表。如果做了预约功能还要加一张排班表和号源表。关键的关联关系是这样的用户表是基础登录表医生和患者都通过 foreign key 关联到用户表问诊订单表记录一次完整的问诊会话里面存患者 ID、医生 ID、订单状态待接诊/进行中/已完成/已取消、问诊类型图文/电话/视频、创建时间问诊记录表则是一问一答的明细数据每一条记录都属于某个订单。处方表挂在订单下面一个订单可以有一份或多份处方处方和药品是多对多关系所以要有中间表存药品数量和用法用量。这里有个细节很容易被忽略订单状态字段千万不要设计成字符串随意填一定要用整数枚举并且在代码里定义一个常量类或者枚举类。比如0表示待支付、1表示待接诊、2表示问诊中、3表示已完成、4表示已取消。这样做的原因是方便后续写状态机逻辑——只有待接诊状态能转成进行中已取消状态不能跳转成已完成这些规则用 if/else 判断数字比判断字符串靠谱得多。3. 多角色权限模型与问诊业务闭环3.1 登录认证从 Session 到 JWT 的取舍在线问诊系统的第一个难点就是多角色登录认证。三种角色如果共用一套登录逻辑那后端拿到登录请求后必须先根据用户名查出用户再判断这个用户属于哪个角色然后决定跳转到哪个首页以及后续接口能拿到哪些数据。传统做法是 Session 认证用户登录成功后后端把用户信息放到 Session 里再给浏览器种一个JSESSIONID的 Cookie后续请求自动携带这个 Cookie后端就能识别身份。这个方案的好处是简单直接Spring Boot 里基本不用写额外代码坏处是前后端如果分离部署跨域时 Cookie 的传递会比较麻烦。我建议在毕设里用 JWTJSON Web Token做登录状态管理。逻辑是用户登录成功后后端把用户 ID、角色 ID、过期时间等信息加密生成一个 token 字符串返回给前端前端每次请求时把 token 放在请求头Authorization里后端写一个拦截器HandlerInterceptor在请求进入 Controller 之前先解析 token校验签名和过期时间然后把用户信息放到 ThreadLocal 里Controller 里直接用。这个过程看起来多写了几十行代码但答辩时你就能讲出无状态认证token 过期刷新接口鉴权这些有含量的词。JWT 的jjwt库用起来很简单我给你一个核心代码片段参考// 生成 token String token Jwts.builder() .setSubject(userId.toString()) .claim(role, roleId) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 解析 token Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody();secretKey要和配置里的保持一致建议用 MD5 或 SHA-256 生成一个固定长度的字符串存到配置文件中。另外token 里千万不要放用户密码这种敏感信息只放 ID 和角色就够了。3.2 拦截器与接口权限控制有了 token 之后接下来就是权限控制。最基础的做法是定义一个拦截器在里面判断当前请求的 URL 是否需要登录才能访问。比如/api/patient/**必须患者登录/api/doctor/**必须医生登录/api/admin/**必须管理员登录。Spring Boot 里可以通过WebMvcConfigurer注册拦截器registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register);然后在拦截器里先检查 token 是否存在再检查角色是否匹配请求路径的前缀。如果角色不对返回 403如果 token 无效或过期返回 401。这个设计在答辩时非常加分因为它体现的不是我会调接口而是我理解越权攻击的危害——一个患者如果拿着自己的 token 去访问医生端接口后端必须拦下来否则就是一个严重的安全漏洞。3.3 问诊流程的状态机设计与实现在线问诊的核心业务逻辑不是 CRUD而是问诊订单的状态流转。我把流程梳理成一条线患者选择科室、医生填写病情描述症状、持续时间、既往病史提交订单。订单初始状态为待接诊同时生成支付单如果是有偿问诊。医生端看到待接诊列表点击接诊订单状态变为问诊中。问诊过程中医患双方通过图文消息或视频通话沟通。医生点击结束问诊填写诊断结论和处方订单状态变为已完成。患者可以对本次服务进行评价。每一步状态变更前端都要给出明确提示后端也要做合法性校验。比如订单处于已完成状态时如果前端又发来一个接诊请求后端要直接拒绝并提示非法状态变更。这块逻辑建议写一个枚举类来管理状态public enum OrderStatus { WAIT_RECEIVE(0, 待接诊), IN_PROGRESS(1, 问诊中), FINISHED(2, 已完成), CANCELED(3, 已取消), WAIT_PAY(4, 待支付); private int code; private String desc; }然后在 Controller 里接收状态时用 code 来比较而不是用自然语言字符串。这样做的好处是数据库存的是数字代码里看的是枚举语义清晰且不容易出错。3.4 在线支付接入支付宝沙箱的完整思路在线问诊系统里问诊通常是付费的所以支付功能是一个绕不开的模块。我建议你接入支付宝的沙箱环境原因有两个一是沙箱环境完全模拟真实支付流程但不涉及真实资金安全性没问题二是支付宝官方有 Java SDK接入难度不大而且答辩时提到真实支付本身就是亮点。支付流程的核心步骤是后端生成一个订单号通常用时间戳加随机数调用支付宝的alipay.trade.page.pay接口生成一个支付表单前端把这个表单渲染出来跳转到支付宝收银台用户支付成功后支付宝以异步通知notify_url的方式回调你的后端接口你在这个回调里更新订单状态。这里有一个特别重要的坑支付回调接口必须做签名验证。支付宝的回调请求里带一个sign参数你要用支付宝的公钥对回调参数做验签验签通过后才能更新订单状态。如果跳过这一步直接信任回调任何知道回调 URL 的人都能伪造支付成功通知这是网上源码最常见的安全漏洞之一。回调处理的伪代码如下RequestMapping(/api/pay/notify) public String payNotify(HttpServletRequest request) { MapString, String params convertRequestToMap(request); boolean verified AlipaySignature.rsaCheckV1(params, alipayPublicKey, UTF-8, RSA2); if (!verified) { return failure; } String orderNo params.get(out_trade_no); String tradeStatus params.get(trade_status); if (TRADE_SUCCESS.equals(tradeStatus)) { orderService.markPaid(orderNo); } return success; }注意返回的字符串必须是success否则支付宝会认为通知失败然后在几分钟内重新回调直到收到success为止。这个机制本身是为了保证幂等但也意味着你的更新订单状态逻辑要做好重复执行的准备——用乐观锁或者状态判断确保同一个回调不会把订单重复置为已支付。4. 核心功能模块实现细解4.1 患者端找医生、提交问诊单、查看报告患者端的核心页面有首页、医生列表、医生详情、问诊单提交、问诊记录、处方查看。我重点说两个设计细节。第一个是找医生这个操作。医生列表不能只拉出一张用户名表一定要做条件筛选按科室筛选、按关键字搜索医生姓名或擅长领域、按评价排序。这些筛选条件在后端对应的是一个动态 SQLMyBatis-Plus 里可以用LambdaQueryWrapper配合like、eq、orderByDesc方法轻松实现。给个示例LambdaQueryWrapperDoctor wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(deptId)) { wrapper.eq(Doctor::getDepartmentId, deptId); } if (StringUtils.hasText(keyword)) { wrapper.and(w - w.like(Doctor::getName, keyword) .or().like(Doctor::getSpecialty, keyword)); } wrapper.orderByDesc(Doctor::getConsultCount); ListDoctor doctors doctorMapper.selectList(wrapper);第二个是问诊单提交时的病情描述表单。我强烈建议你做成结构化表单而不是一个单纯的大文本域。什么叫结构化就是让用户选择主要症状多选、填写持续时间天数、补充详细描述文本域、上传图片检查报告照片。这样设计的好处是医生拿到问诊单时能看到清晰的结构化信息而不是一段毫无重点的流水账。后台存数据时主症状可以用字符串数组或 JSON 格式存储在单独的字段里方便后续做数据分析和病历归档。患者在提交问诊单后整个流程里最关心的就是医生有没有回我。所以问诊记录列表页需要做主动刷新或短轮询每隔 5 到 10 秒请求一次最新状态状态变了就更新页面。为什么用短轮询而不是 WebSocket因为毕设阶段 WebSocket 的并发管理、心跳机制、掉线重连这些坑足够你折腾一星期短轮询虽然不优雅但稳定、好解释答辩时坦白说这里用短轮询保证简单可靠比强行上 WebSocket 最后说不清楚好得多。4.2 医生端接诊、回复消息、开处方医生端的最核心页面是问诊工作台。这个页面集合了三个子功能待接诊的订单列表、正在进行的会话窗口、诊断与处方填写面板。待接诊列表用 Tab 页签切分待接诊和进行中两个视图每个订单卡片展示患者基本信息、主诉摘要、等待时长。接诊操作和拒绝操作要分开放拒绝时必须填写理由防止医生无理由拒单。这里有个很实用的交互细节接诊按钮点击后要加一个 3 秒的确认弹窗防止误触同时检查订单状态是否还是待接诊——因为可能存在多个医生同时抢单的极端情况虽然毕设里不做这么复杂的并发控制但状态校验必须写。会话窗口其实就是聊天室需要数据库一张表来存聊天记录并支持分页加载。我用的是 WebSocket 做实时消息推送但实现思路是前端 WebSocket 建立连接后后端把连接对象和用户 ID 绑定到一个 ConcurrentHashMap 中当患者发送消息时后端先存库再通过连接池找到对应的医生连接把消息推过去。医生回复的流程同理。如果你不想用 WebSocket可以用前面提到的短轮询方案每 3 秒查一次新消息也不影响演示效果。开处方是整个医生端里逻辑最复杂的表单。一张处方包含多个药品项目每个药品有名称、剂型、单次剂量、用药频次、用药天数、总量、用法备注。前端要用动态表格来实现逐行添加药品的操作提交时后端接收的是一个药品 ID 数组和一个用量数组。这里我建议你在后端用一个专门的PrescriptionDTO来接收内部包含ListPrescriptionItem每个 item 有药品 ID、剂量、频次等字段。接收后在一个事务里同时写入处方主表和处方明细表。4.3 管理员端资质审核、科室与药品管理管理员端的核心职责是维护系统的基础数据和审核医生的入驻资质。我把这部分拆成三个模块来讲。首先是医生资质审核。当一个医生注册后他的账号默认状态是待审核只能看到自己的入驻进度不能接诊。管理员在后台看到医生列表点击查看详情能看到医生填写的执业证书编号、职称、擅长领域、身份证照片等资质信息。审核通过后修改医生的状态字段为已通过医生端的登录跳转逻辑才会允许他进入到工作台。这个设计在答辩里很加分因为它体现了平台型产品必须有人审机制这个业务常识。其次是科室管理。科室的本质是一棵简单的两级树一级科室内科、外科、儿科、妇产科二级科室心血管内科、呼吸内科、消化内科。管理员可以对科室进行增删改查医生入驻时选择二级科室患者找医生时按一级科室筛选后端通过二级科室的父子关系来做关联查询。再是药品管理。药品的几个关键字段是通用名、商品名、规格、生产厂家、是否处方药、库存数量、单价。其中是否处方药这个字段非常重要因为开具处方时非处方药不需要医生签字而处方药必须有明确的用量和用法代码层面要做校验。库存字段要注意的是开处方减少库存不应该是简单做减法——多个医生同时开同一种药时可能会出现超卖需要把库存扣除这个操作放在一个带条件的 UPDATE 语句里int rows drugMapper.updateStock(drugId, count); // update stock set stock stock - {count} where id {drugId} and stock {count}如果rows 0说明库存不足需要回滚整个处方事务。这其实就是乐观锁的一种变体答辩时可以把这个点拎出来讲并发控制非常加分。4.4 消息通知系统通知与问诊提醒的实现在线问诊系统里通知是一个容易被忽略但实际使用频率很高的功能。通知的类型分为三类系统广播管理员发布的公告、订单状态变更通知订单被接诊了、订单完成了、问诊提醒医生上线提醒患者、预约时间快到了提醒医生。最简单的实现方案是建一张通知表字段包括接收人 ID、通知类型、内容、是否已读、创建时间。后端在订单状态变更时通过 Spring 的事件机制发布一个通知事件由监听器异步写入通知表。前端可以用一个定时任务每隔 30 秒拉取未读通知数量在右上角的小铃铛上显示数字角标。这里我用了一个 Spring 内置的Async注解来异步写库还顺便在配置里开了线程池Async(notificationExecutor) public void sendNotification(Long userId, NotificationVO vo) { notificationMapper.insert(convert(vo)); }这样做的原因是通知写入不应该阻塞主流程——用户支付成功后他应该立刻看到支付成功的响应而不是等通知表写入完成才返回。这个异步化的思路虽然只是一个小点但能在答辩时展示你对响应时间和并发考虑的理解。5. 开发过程中的典型问题与排查记录5.1 跨域问题前后端分离的第一道坎如果你做的是前后端分离项目第一次调试接口时大概率会遇到这个报错Access to XMLHttpRequest has been blocked by CORS policy。原因很简单前端跑在http://localhost:5173后端跑在http://localhost:8080端口不同浏览器就认为这是跨域请求默认拦截掉。解决办法有几种最简单的方案是后端加一个 CORS 配置类允许前端的源访问后端接口Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true); } }还有一点要注意如果你引入了 Spring Security那光配 CorsConfig 还不够因为 Security 的过滤器链会在你的配置之前拦截请求需要在 SecurityConfig 里也放行 OPTIONS 预检请求。很多人在这一步卡了很久最后发现是 Security 拦截器把OPTIONS请求当成匿名请求拒掉了。5.2 JWT 过期后的体验问题JWT 的过期时间我一般设置成 7 天这样在校期间做演示基本不需要重新登录。但如果你做了记住我功能那 token 过期后用户应该能通过一个 refresh_token 来刷新而不用重新输密码。refresh_token 的过期时间可以设成 14 天或 30 天它并不需要存到数据库只要用同一个密钥加密、带上一个标识这是 refresh_token的 claim 即可。前端这边的处理逻辑是在 axios 拦截器里判断响应状态码如果是 401就自动调一次刷新接口刷新成功就重放原来的请求刷新失败就跳转到登录页。这个机制在真实项目里是标配在毕设里做出来也会让答辩老师眼前一亮。5.3 事务失效的常见原因同类调用与 try-catch开处方是一个典型的需要事务保护的操作——主表和明细表要么同时写入成功要么同时失败。Spring 的事务很好用但有两个坑我必须在文章里强调。第一个坑是同类调用导致事务失效。如果你在一个 Service 里定义了一个Transactional方法然后从同类里另一个非事务方法直接调用它事务是不会生效的。原因是 Spring 事务基于代理机制同类方法直接调用走的是 this 调用绕过了代理。解决办法是把事务方法放到单独的 Service 类里或者通过注入自己的代理对象然后调用。第二个坑是try-catch 吞掉异常。如你在Transactional方法内部用 try-catch 捕获了异常并且没有抛出事务管理器就感知不到异常不会回滚。正确做法是捕获后重新抛出RuntimeException或者标记需要回滚。try { prescriptionMapper.insert(main); itemList.forEach(item - itemMapper.insert(item)); } catch (Exception e) { log.error(处方写入失败, e); throw new RuntimeException(处方保存失败已回滚); }这块代码在答辩时被问概率极高建议把代理机制和异常传播这两条原理背熟。5.4 文件上传患者上传检查报告的完整处理患者提交问诊单时需要上传检查报告图片这个功能看似简单但藏了不少细节。首先存储路径要单独配置到项目外部不能存在 target 或 classes 目录下否则每次重新打包编译上传的图片就丢了。我惯用的方案是在配置里写一个绝对路径file.upload-dir/data/medical/upload/然后在 WebMvcConfigurer 里配置一个资源映射把 URL 为/upload/**的请求映射到这个磁盘路径registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/medical/upload/);前端展示时就拼接upload/ 文件名即可完全不用经过后端 Controller 读取。第二个坑是文件类型校验一定要在 Controller 入口检查文件的扩展名和 Content-Type防止用户上传可执行文件造成安全问题。第三个坑是文件命名不要用用户原始文件名用 UUID 或者时间戳加随机数生成新名字避免中文文件名和重名问题。5.5 MyBatis-Plus 分页插件失效的排查用 MyBatis-Plus 时如果你写了分页查询但发现返回的结果里total总是 0或者压根没拼上 LIMIT 语句八成是因为你没配置分页插件。MyBatis-Plus 3.x 以后的分页插件不再是默认开启的必须手动注册Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }排查这个问题时先打开 MyBatis 的 SQL 日志看控制台打印出的 SQL 末尾有没有 LIMIT如果没有确认拦截器是否注册成功如果注册了还没用检查一下实体类上有没有透传分页参数以及Page对象是否作为第一个参数传入了 Mapper 方法。6. 项目复盘与效果评估系统开发完成后我把整个项目的运行效果又完整走查了一遍。问诊流程的完整链路患者注册登录、选择科室、找到医生、填写问诊单、模拟支付、等待接诊医生登录工作台、接诊、回复消息、开处方、结束问诊患者查看处方详情管理员审核入驻医生、管理药品库存。整个串联过程中数据是一致的状态流转是可控的权限边界是清晰的。我特意做了一个边界测试用患者的账号直接访问医生接诊接口返回 403用未登录的 token 访问任意接口返回 401重复提交同一个支付回调订单不会变成两条已支付记录库存不足时处方提交会被整体回滚并提示用户。这些测试结果让我对这个系统的信心提升了不少也因为提前做了这些边界测试答辩时被追问如果用户恶意请求怎么办的时候我能直接给出代码层面的回答。从技术指标的维度看系统接口的平均响应时间在本地环境大约在 20-50ms问诊消息通过 WebSocket 推送的端到端延迟基本在可感知范围内高峰期并发虽然不是毕设考察的重点但我已经通过数据库索引和缓存设计做了预留。这里有个很意外的小收获因为做的是在线问诊系统的数据表设计我被迫去认真梳理了用户表与医生扩展信息的垂直拆分问题。一开始我想把所有字段塞到一张 user 表里后来发现医生有职称、执业编号、擅长领域患者有身份证号、历史病历这些字段堆在一起既臃肿又容易出查询性能问题。最后采用了主表加扩展表的方案——user 表只放公共字段医生和患者各自建扩展表通过主键关联。这种设计不仅让表结构看起来专业也让我在后面的代码编写中少吃了很多苦头。若后续要在这个项目上继续扩展我个人觉得最有价值的两个方向是引入消息队列做问诊高峰期的削峰填谷以及用 Redis 缓存热门医生的号源数据并把扣减操作做成原子性的。这两个点都属于把毕设工程化、企业化的典型升级路径如果毕设之外还有余力非常建议去试一下到了面试的时候这两个话题能聊出来的深度完全不是一个量级的。
Spring Boot在线问诊系统实战：多角色权限与问诊状态机设计
1. 项目概述与选题思路这两年我带过的毕设小组里至少有一半人第一眼看到在线问诊系统这个题目时会觉得它不就是个增删改查吗。说实话这个判断对了一半——如果只想做一个能跑起来的 demo那确实就是一个带了权限控制的 CRUD但如果你愿意往深处走一层这个题目其实能挖出非常多值得写在简历上的东西比如多角色权限模型设计、问诊会话的状态机流转、支付与订单对账、消息推送的延迟与重试、甚至医生排班和号源锁定的并发问题。先说这个系统到底是干什么的。一句话概括它把一个线下医院的问诊流程搬到了 Web 端让患者可以在线找医生、提交病情描述、预约问诊时间医生可以接诊、查看病历、给出诊断建议和处方管理员负责审核医生资质、管理科室与药品信息、查看平台运营数据。整个系统里有三种基础角色患者、医生、管理员后期还能扩展药师、护士等辅助角色。从毕设选题的角度来看这个题目有几个天然优势。其一业务场景足够贴近生活答辩时评委不需要你解释半天你这个系统是干嘛的demo 演示直观其二技术覆盖面广既能体现 Java 基础集合、异常、多线程又能体现 Web 开发能力Servlet/Spring MVC、前端交互、会话管理还能体现数据库设计能力ER 建模、事务、索引一个题目把大学四年学的东西基本都串起来了其三后期可以随时加亮点功能比如接入了 WebSocket 实现医生与患者的实时对话或者用 Redis 做号源缓存或者用 RabbitMQ 做异步消息通知这些都是加分项。但我也要提前泼一盆冷水正因为这个题目常见答辩时老师见过的同类系统非常多如果你只是把别人的代码换个皮交上去很容易被问倒。真正能拿高分的做法是把多角色权限边界和问诊流程的完整闭环这两个核心点做扎实让老师感受到你是真的理解了业务而不是背了几个注解。2. 技术选型与项目结构设计2.1 后端框架怎么选才不会翻车先说框架。现在 2025 年还在用纯 JSP Servlet 写新项目的人确实不多了除非你们学校硬性要求不能用框架。如果让我推荐Spring Boot 是绝对的首选原因很简单它把以前 Spring MVC 项目里繁琐的 XML 配置全部约定化你只要引入几个 starter写一个启动类项目就能跑起来。而且毕设答辩时老师最关心的几个问题——依赖管理、自动配置、内嵌 Tomcat——都是 Spring Boot 的核心特性你天然就站在了一个能讲出东西的位置上。具体版本建议用 Spring Boot 2.7.x 或者 3.x看你自己 JDK 的版本。如果 JDK 是 8那就老老实实用 2.7.x别硬上 3.x因为 Spring Boot 3 要求 JDK 17 起步到时候环境变量折腾半天纯粹是给自己找麻烦。我见过不止一个学生因为版本不匹配在启动阶段就卡了一整天最后发现是 JDK 和 Spring Boot 的大版本对不上。MyBatis 和 MyBatis-Plus 怎么选我的建议是直接用 MyBatis-Plus。理由不是什么国产框架更友好而是它内置的 BaseMapper 能把你从重复的单表 CRUD 里解放出来让你把精力放在真正的业务逻辑上。更重要的是Plus 的分页插件真的很好用你写一个PageUser对象插件自动帮你拼 LIMIT 语句连 count 查询都帮你优化了。答辩时老师问你怎么做分页的你至少能答出物理分页和逻辑分页的区别——物理分页是数据库层面用 LIMIT 截断逻辑分页是查出全部数据后在内存里截取Plus 默认走物理分页性能更好。2.2 前端方案别在花里胡哨上浪费时间前端可能是很多 Java 选手最头疼的部分但我必须说一句毕设的前端真的不需要你做出花来。我见过有人用 Vue 3 Element Plus 搭了一套非常精致的管理后台结果时间全耗在前端样式上了后端逻辑反而写得稀烂答辩时被问得哑口无言——这就是典型的本末倒置。最稳妥的方案是后端用 Spring Boot 提供 JSON 接口前端用 Thymeleaf 模板引擎渲染页面结合 Bootstrap 或 Layui 做样式。为什么选 Thymeleaf因为它和 Spring Boot 无缝集成你只需要在pom.xml里加一个spring-boot-starter-thymeleaf依赖然后在application.properties里配一下前缀后缀路径页面里用th:each、th:if这些语法就能直接渲染后端传过来的数据。这比 Vue 少了跨域处理、前端路由、状态管理一堆麻烦事对于毕设来说完全够用。当然如果你觉得自己的前端能力还行也有多余的时间用 Vue 3 Element Plus 做一个前后端分离版本是可以加分的但前提是你必须把 token 认证、跨域配置、axios 封装这些东西讲清楚否则评委一眼就看出你是网上抄的模板。2.3 数据库设计在线问诊的核心是表关系数据库设计是整个系统里我最想强调的部分因为很多人的表结构一拿出来就知道是临时凑的——字段命名随意、主外键关系混乱、没有考虑索引。在线问诊系统最少需要这九张表用户表、医生信息表含科室和职称、科室表、患者信息表、问诊订单表、问诊记录表消息记录或诊断记录、处方表含药品明细、药品表、管理员表。如果做了预约功能还要加一张排班表和号源表。关键的关联关系是这样的用户表是基础登录表医生和患者都通过 foreign key 关联到用户表问诊订单表记录一次完整的问诊会话里面存患者 ID、医生 ID、订单状态待接诊/进行中/已完成/已取消、问诊类型图文/电话/视频、创建时间问诊记录表则是一问一答的明细数据每一条记录都属于某个订单。处方表挂在订单下面一个订单可以有一份或多份处方处方和药品是多对多关系所以要有中间表存药品数量和用法用量。这里有个细节很容易被忽略订单状态字段千万不要设计成字符串随意填一定要用整数枚举并且在代码里定义一个常量类或者枚举类。比如0表示待支付、1表示待接诊、2表示问诊中、3表示已完成、4表示已取消。这样做的原因是方便后续写状态机逻辑——只有待接诊状态能转成进行中已取消状态不能跳转成已完成这些规则用 if/else 判断数字比判断字符串靠谱得多。3. 多角色权限模型与问诊业务闭环3.1 登录认证从 Session 到 JWT 的取舍在线问诊系统的第一个难点就是多角色登录认证。三种角色如果共用一套登录逻辑那后端拿到登录请求后必须先根据用户名查出用户再判断这个用户属于哪个角色然后决定跳转到哪个首页以及后续接口能拿到哪些数据。传统做法是 Session 认证用户登录成功后后端把用户信息放到 Session 里再给浏览器种一个JSESSIONID的 Cookie后续请求自动携带这个 Cookie后端就能识别身份。这个方案的好处是简单直接Spring Boot 里基本不用写额外代码坏处是前后端如果分离部署跨域时 Cookie 的传递会比较麻烦。我建议在毕设里用 JWTJSON Web Token做登录状态管理。逻辑是用户登录成功后后端把用户 ID、角色 ID、过期时间等信息加密生成一个 token 字符串返回给前端前端每次请求时把 token 放在请求头Authorization里后端写一个拦截器HandlerInterceptor在请求进入 Controller 之前先解析 token校验签名和过期时间然后把用户信息放到 ThreadLocal 里Controller 里直接用。这个过程看起来多写了几十行代码但答辩时你就能讲出无状态认证token 过期刷新接口鉴权这些有含量的词。JWT 的jjwt库用起来很简单我给你一个核心代码片段参考// 生成 token String token Jwts.builder() .setSubject(userId.toString()) .claim(role, roleId) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 解析 token Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody();secretKey要和配置里的保持一致建议用 MD5 或 SHA-256 生成一个固定长度的字符串存到配置文件中。另外token 里千万不要放用户密码这种敏感信息只放 ID 和角色就够了。3.2 拦截器与接口权限控制有了 token 之后接下来就是权限控制。最基础的做法是定义一个拦截器在里面判断当前请求的 URL 是否需要登录才能访问。比如/api/patient/**必须患者登录/api/doctor/**必须医生登录/api/admin/**必须管理员登录。Spring Boot 里可以通过WebMvcConfigurer注册拦截器registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register);然后在拦截器里先检查 token 是否存在再检查角色是否匹配请求路径的前缀。如果角色不对返回 403如果 token 无效或过期返回 401。这个设计在答辩时非常加分因为它体现的不是我会调接口而是我理解越权攻击的危害——一个患者如果拿着自己的 token 去访问医生端接口后端必须拦下来否则就是一个严重的安全漏洞。3.3 问诊流程的状态机设计与实现在线问诊的核心业务逻辑不是 CRUD而是问诊订单的状态流转。我把流程梳理成一条线患者选择科室、医生填写病情描述症状、持续时间、既往病史提交订单。订单初始状态为待接诊同时生成支付单如果是有偿问诊。医生端看到待接诊列表点击接诊订单状态变为问诊中。问诊过程中医患双方通过图文消息或视频通话沟通。医生点击结束问诊填写诊断结论和处方订单状态变为已完成。患者可以对本次服务进行评价。每一步状态变更前端都要给出明确提示后端也要做合法性校验。比如订单处于已完成状态时如果前端又发来一个接诊请求后端要直接拒绝并提示非法状态变更。这块逻辑建议写一个枚举类来管理状态public enum OrderStatus { WAIT_RECEIVE(0, 待接诊), IN_PROGRESS(1, 问诊中), FINISHED(2, 已完成), CANCELED(3, 已取消), WAIT_PAY(4, 待支付); private int code; private String desc; }然后在 Controller 里接收状态时用 code 来比较而不是用自然语言字符串。这样做的好处是数据库存的是数字代码里看的是枚举语义清晰且不容易出错。3.4 在线支付接入支付宝沙箱的完整思路在线问诊系统里问诊通常是付费的所以支付功能是一个绕不开的模块。我建议你接入支付宝的沙箱环境原因有两个一是沙箱环境完全模拟真实支付流程但不涉及真实资金安全性没问题二是支付宝官方有 Java SDK接入难度不大而且答辩时提到真实支付本身就是亮点。支付流程的核心步骤是后端生成一个订单号通常用时间戳加随机数调用支付宝的alipay.trade.page.pay接口生成一个支付表单前端把这个表单渲染出来跳转到支付宝收银台用户支付成功后支付宝以异步通知notify_url的方式回调你的后端接口你在这个回调里更新订单状态。这里有一个特别重要的坑支付回调接口必须做签名验证。支付宝的回调请求里带一个sign参数你要用支付宝的公钥对回调参数做验签验签通过后才能更新订单状态。如果跳过这一步直接信任回调任何知道回调 URL 的人都能伪造支付成功通知这是网上源码最常见的安全漏洞之一。回调处理的伪代码如下RequestMapping(/api/pay/notify) public String payNotify(HttpServletRequest request) { MapString, String params convertRequestToMap(request); boolean verified AlipaySignature.rsaCheckV1(params, alipayPublicKey, UTF-8, RSA2); if (!verified) { return failure; } String orderNo params.get(out_trade_no); String tradeStatus params.get(trade_status); if (TRADE_SUCCESS.equals(tradeStatus)) { orderService.markPaid(orderNo); } return success; }注意返回的字符串必须是success否则支付宝会认为通知失败然后在几分钟内重新回调直到收到success为止。这个机制本身是为了保证幂等但也意味着你的更新订单状态逻辑要做好重复执行的准备——用乐观锁或者状态判断确保同一个回调不会把订单重复置为已支付。4. 核心功能模块实现细解4.1 患者端找医生、提交问诊单、查看报告患者端的核心页面有首页、医生列表、医生详情、问诊单提交、问诊记录、处方查看。我重点说两个设计细节。第一个是找医生这个操作。医生列表不能只拉出一张用户名表一定要做条件筛选按科室筛选、按关键字搜索医生姓名或擅长领域、按评价排序。这些筛选条件在后端对应的是一个动态 SQLMyBatis-Plus 里可以用LambdaQueryWrapper配合like、eq、orderByDesc方法轻松实现。给个示例LambdaQueryWrapperDoctor wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(deptId)) { wrapper.eq(Doctor::getDepartmentId, deptId); } if (StringUtils.hasText(keyword)) { wrapper.and(w - w.like(Doctor::getName, keyword) .or().like(Doctor::getSpecialty, keyword)); } wrapper.orderByDesc(Doctor::getConsultCount); ListDoctor doctors doctorMapper.selectList(wrapper);第二个是问诊单提交时的病情描述表单。我强烈建议你做成结构化表单而不是一个单纯的大文本域。什么叫结构化就是让用户选择主要症状多选、填写持续时间天数、补充详细描述文本域、上传图片检查报告照片。这样设计的好处是医生拿到问诊单时能看到清晰的结构化信息而不是一段毫无重点的流水账。后台存数据时主症状可以用字符串数组或 JSON 格式存储在单独的字段里方便后续做数据分析和病历归档。患者在提交问诊单后整个流程里最关心的就是医生有没有回我。所以问诊记录列表页需要做主动刷新或短轮询每隔 5 到 10 秒请求一次最新状态状态变了就更新页面。为什么用短轮询而不是 WebSocket因为毕设阶段 WebSocket 的并发管理、心跳机制、掉线重连这些坑足够你折腾一星期短轮询虽然不优雅但稳定、好解释答辩时坦白说这里用短轮询保证简单可靠比强行上 WebSocket 最后说不清楚好得多。4.2 医生端接诊、回复消息、开处方医生端的最核心页面是问诊工作台。这个页面集合了三个子功能待接诊的订单列表、正在进行的会话窗口、诊断与处方填写面板。待接诊列表用 Tab 页签切分待接诊和进行中两个视图每个订单卡片展示患者基本信息、主诉摘要、等待时长。接诊操作和拒绝操作要分开放拒绝时必须填写理由防止医生无理由拒单。这里有个很实用的交互细节接诊按钮点击后要加一个 3 秒的确认弹窗防止误触同时检查订单状态是否还是待接诊——因为可能存在多个医生同时抢单的极端情况虽然毕设里不做这么复杂的并发控制但状态校验必须写。会话窗口其实就是聊天室需要数据库一张表来存聊天记录并支持分页加载。我用的是 WebSocket 做实时消息推送但实现思路是前端 WebSocket 建立连接后后端把连接对象和用户 ID 绑定到一个 ConcurrentHashMap 中当患者发送消息时后端先存库再通过连接池找到对应的医生连接把消息推过去。医生回复的流程同理。如果你不想用 WebSocket可以用前面提到的短轮询方案每 3 秒查一次新消息也不影响演示效果。开处方是整个医生端里逻辑最复杂的表单。一张处方包含多个药品项目每个药品有名称、剂型、单次剂量、用药频次、用药天数、总量、用法备注。前端要用动态表格来实现逐行添加药品的操作提交时后端接收的是一个药品 ID 数组和一个用量数组。这里我建议你在后端用一个专门的PrescriptionDTO来接收内部包含ListPrescriptionItem每个 item 有药品 ID、剂量、频次等字段。接收后在一个事务里同时写入处方主表和处方明细表。4.3 管理员端资质审核、科室与药品管理管理员端的核心职责是维护系统的基础数据和审核医生的入驻资质。我把这部分拆成三个模块来讲。首先是医生资质审核。当一个医生注册后他的账号默认状态是待审核只能看到自己的入驻进度不能接诊。管理员在后台看到医生列表点击查看详情能看到医生填写的执业证书编号、职称、擅长领域、身份证照片等资质信息。审核通过后修改医生的状态字段为已通过医生端的登录跳转逻辑才会允许他进入到工作台。这个设计在答辩里很加分因为它体现了平台型产品必须有人审机制这个业务常识。其次是科室管理。科室的本质是一棵简单的两级树一级科室内科、外科、儿科、妇产科二级科室心血管内科、呼吸内科、消化内科。管理员可以对科室进行增删改查医生入驻时选择二级科室患者找医生时按一级科室筛选后端通过二级科室的父子关系来做关联查询。再是药品管理。药品的几个关键字段是通用名、商品名、规格、生产厂家、是否处方药、库存数量、单价。其中是否处方药这个字段非常重要因为开具处方时非处方药不需要医生签字而处方药必须有明确的用量和用法代码层面要做校验。库存字段要注意的是开处方减少库存不应该是简单做减法——多个医生同时开同一种药时可能会出现超卖需要把库存扣除这个操作放在一个带条件的 UPDATE 语句里int rows drugMapper.updateStock(drugId, count); // update stock set stock stock - {count} where id {drugId} and stock {count}如果rows 0说明库存不足需要回滚整个处方事务。这其实就是乐观锁的一种变体答辩时可以把这个点拎出来讲并发控制非常加分。4.4 消息通知系统通知与问诊提醒的实现在线问诊系统里通知是一个容易被忽略但实际使用频率很高的功能。通知的类型分为三类系统广播管理员发布的公告、订单状态变更通知订单被接诊了、订单完成了、问诊提醒医生上线提醒患者、预约时间快到了提醒医生。最简单的实现方案是建一张通知表字段包括接收人 ID、通知类型、内容、是否已读、创建时间。后端在订单状态变更时通过 Spring 的事件机制发布一个通知事件由监听器异步写入通知表。前端可以用一个定时任务每隔 30 秒拉取未读通知数量在右上角的小铃铛上显示数字角标。这里我用了一个 Spring 内置的Async注解来异步写库还顺便在配置里开了线程池Async(notificationExecutor) public void sendNotification(Long userId, NotificationVO vo) { notificationMapper.insert(convert(vo)); }这样做的原因是通知写入不应该阻塞主流程——用户支付成功后他应该立刻看到支付成功的响应而不是等通知表写入完成才返回。这个异步化的思路虽然只是一个小点但能在答辩时展示你对响应时间和并发考虑的理解。5. 开发过程中的典型问题与排查记录5.1 跨域问题前后端分离的第一道坎如果你做的是前后端分离项目第一次调试接口时大概率会遇到这个报错Access to XMLHttpRequest has been blocked by CORS policy。原因很简单前端跑在http://localhost:5173后端跑在http://localhost:8080端口不同浏览器就认为这是跨域请求默认拦截掉。解决办法有几种最简单的方案是后端加一个 CORS 配置类允许前端的源访问后端接口Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true); } }还有一点要注意如果你引入了 Spring Security那光配 CorsConfig 还不够因为 Security 的过滤器链会在你的配置之前拦截请求需要在 SecurityConfig 里也放行 OPTIONS 预检请求。很多人在这一步卡了很久最后发现是 Security 拦截器把OPTIONS请求当成匿名请求拒掉了。5.2 JWT 过期后的体验问题JWT 的过期时间我一般设置成 7 天这样在校期间做演示基本不需要重新登录。但如果你做了记住我功能那 token 过期后用户应该能通过一个 refresh_token 来刷新而不用重新输密码。refresh_token 的过期时间可以设成 14 天或 30 天它并不需要存到数据库只要用同一个密钥加密、带上一个标识这是 refresh_token的 claim 即可。前端这边的处理逻辑是在 axios 拦截器里判断响应状态码如果是 401就自动调一次刷新接口刷新成功就重放原来的请求刷新失败就跳转到登录页。这个机制在真实项目里是标配在毕设里做出来也会让答辩老师眼前一亮。5.3 事务失效的常见原因同类调用与 try-catch开处方是一个典型的需要事务保护的操作——主表和明细表要么同时写入成功要么同时失败。Spring 的事务很好用但有两个坑我必须在文章里强调。第一个坑是同类调用导致事务失效。如果你在一个 Service 里定义了一个Transactional方法然后从同类里另一个非事务方法直接调用它事务是不会生效的。原因是 Spring 事务基于代理机制同类方法直接调用走的是 this 调用绕过了代理。解决办法是把事务方法放到单独的 Service 类里或者通过注入自己的代理对象然后调用。第二个坑是try-catch 吞掉异常。如你在Transactional方法内部用 try-catch 捕获了异常并且没有抛出事务管理器就感知不到异常不会回滚。正确做法是捕获后重新抛出RuntimeException或者标记需要回滚。try { prescriptionMapper.insert(main); itemList.forEach(item - itemMapper.insert(item)); } catch (Exception e) { log.error(处方写入失败, e); throw new RuntimeException(处方保存失败已回滚); }这块代码在答辩时被问概率极高建议把代理机制和异常传播这两条原理背熟。5.4 文件上传患者上传检查报告的完整处理患者提交问诊单时需要上传检查报告图片这个功能看似简单但藏了不少细节。首先存储路径要单独配置到项目外部不能存在 target 或 classes 目录下否则每次重新打包编译上传的图片就丢了。我惯用的方案是在配置里写一个绝对路径file.upload-dir/data/medical/upload/然后在 WebMvcConfigurer 里配置一个资源映射把 URL 为/upload/**的请求映射到这个磁盘路径registry.addResourceHandler(/upload/**) .addResourceLocations(file:/data/medical/upload/);前端展示时就拼接upload/ 文件名即可完全不用经过后端 Controller 读取。第二个坑是文件类型校验一定要在 Controller 入口检查文件的扩展名和 Content-Type防止用户上传可执行文件造成安全问题。第三个坑是文件命名不要用用户原始文件名用 UUID 或者时间戳加随机数生成新名字避免中文文件名和重名问题。5.5 MyBatis-Plus 分页插件失效的排查用 MyBatis-Plus 时如果你写了分页查询但发现返回的结果里total总是 0或者压根没拼上 LIMIT 语句八成是因为你没配置分页插件。MyBatis-Plus 3.x 以后的分页插件不再是默认开启的必须手动注册Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }排查这个问题时先打开 MyBatis 的 SQL 日志看控制台打印出的 SQL 末尾有没有 LIMIT如果没有确认拦截器是否注册成功如果注册了还没用检查一下实体类上有没有透传分页参数以及Page对象是否作为第一个参数传入了 Mapper 方法。6. 项目复盘与效果评估系统开发完成后我把整个项目的运行效果又完整走查了一遍。问诊流程的完整链路患者注册登录、选择科室、找到医生、填写问诊单、模拟支付、等待接诊医生登录工作台、接诊、回复消息、开处方、结束问诊患者查看处方详情管理员审核入驻医生、管理药品库存。整个串联过程中数据是一致的状态流转是可控的权限边界是清晰的。我特意做了一个边界测试用患者的账号直接访问医生接诊接口返回 403用未登录的 token 访问任意接口返回 401重复提交同一个支付回调订单不会变成两条已支付记录库存不足时处方提交会被整体回滚并提示用户。这些测试结果让我对这个系统的信心提升了不少也因为提前做了这些边界测试答辩时被追问如果用户恶意请求怎么办的时候我能直接给出代码层面的回答。从技术指标的维度看系统接口的平均响应时间在本地环境大约在 20-50ms问诊消息通过 WebSocket 推送的端到端延迟基本在可感知范围内高峰期并发虽然不是毕设考察的重点但我已经通过数据库索引和缓存设计做了预留。这里有个很意外的小收获因为做的是在线问诊系统的数据表设计我被迫去认真梳理了用户表与医生扩展信息的垂直拆分问题。一开始我想把所有字段塞到一张 user 表里后来发现医生有职称、执业编号、擅长领域患者有身份证号、历史病历这些字段堆在一起既臃肿又容易出查询性能问题。最后采用了主表加扩展表的方案——user 表只放公共字段医生和患者各自建扩展表通过主键关联。这种设计不仅让表结构看起来专业也让我在后面的代码编写中少吃了很多苦头。若后续要在这个项目上继续扩展我个人觉得最有价值的两个方向是引入消息队列做问诊高峰期的削峰填谷以及用 Redis 缓存热门医生的号源数据并把扣减操作做成原子性的。这两个点都属于把毕设工程化、企业化的典型升级路径如果毕设之外还有余力非常建议去试一下到了面试的时候这两个话题能聊出来的深度完全不是一个量级的。