每年到了毕设季Java 方向的同学问得最多的问题就是“做什么题目”。选电商系统太腻选管理系统太水选算法类又怕自己啃不动。如果你正在这个阶段纠结我建议认真看一眼在线问诊系统这个方向——它用 SpringBoot 做后端、走 Java Web 技术栈既能体现业务建模能力又有并发控制、状态机、权限认证这些可深挖的技术点工作量也刚好卡在“一个人能做完”的范围内。这篇博文不打算只给你一份功能清单而是把从选题、建模、编码到答辩的完整思路讲透适合准备做毕设的学生也适合刚入门 SpringBoot 想找个完整项目练手的人。1. 为什么这个题目值得做角色划分、功能矩阵与技术栈取舍1.1 先想清楚系统边界核心闭环、可选延展、明确不做我见过太多学生拿到题目就开始写代码结果写了一个月发现功能越加越多数据库改了十几版最后论文都编不下去。在线问诊系统这个题目最理想的做法是先把自己围在一个能跑通的核心闭环里。核心闭环就是用户注册登录 → 选择科室和医生 → 查看排班 → 在线挂号 → 发起图文问诊 → 医生回复 → 医生开处方 → 患者查看处方并结束问诊。能把这个链路完整跑通你的毕设已经及格了。在这个基础上可以延展的功能包括科室管理、医生排班管理、患者健康档案、历史问诊记录、管理员数据统计、公告和消息通知。这些属于“加分项”在核心链路完成之后逐个加上去不会伤筋动骨。更要命的是要明确“哪些不做”。很多同学一上来就想接入在线支付、视频问诊、电子病历互联互通这些功能会把你的项目带进深渊。在线支付涉及第三方对接和资质视频问诊需要 WebRTC 或第三方 SDK不是在一个毕设周期能打磨好的。你要在论文里写清楚这个系统的边界这反而会让答辩老师觉得你设计思路清晰。1.2 三类角色的权限划分与功能矩阵在线问诊系统最常见的角色划分是三类患者、医生、管理员。权限设计不宜搞得太复杂用一张角色表加上接口层面的角色校验就能搞定但是功能矩阵必须想清楚。患者端功能注册登录、浏览科室和医生列表、查看医生排班、在线挂号、发起问诊、查看问诊记录与处方、个人资料维护。医生端功能查看排班、处理待接诊的问诊单、回复患者消息、结束问诊、开具处方、查看历史接诊记录。管理员端功能审核医生信息、管理科室、管理排班数据、查看系统统计数据。这里有个容易忽略的细节医生不是平台自己的员工而是“入驻”的。所以医生需要有一个入驻申请和管理员审核的流程哪怕你只是用一个 status 字段从 0 改成 1也比你写死一个医生账号要专业得多。这个流程在论文里能写成“平台准入机制”一下子就有了业务深度。1.3 技术栈选型为什么是 SpringBoot MyBatis-Plus MySQL Redis很多同学的选题本身没问题但技术栈选得让人捏把汗。如果是纯 Java Web 方向的毕设我强烈建议后端用 SpringBoot前端用 Vue 做前后端分离数据库用 MySQL缓存用 RedisORM 用 MyBatis-Plus。为什么不用传统的 SSM 加 JSP不是说 SSM 不能做而是 SpringBoot 已经是这个时代 Java Web 开发的默认起点。它通过 starter 机制把依赖管理简化了内嵌 Tomcat 让你不用再部署 war 包这些特性可以让你把精力放到业务上而不是配置文件里。论文的对比章节也更好写SpringBoot 的自动配置、约定优于配置、生态成熟度都是现成的素材。MyBatis-Plus 的价值在于单表 CRUD 几乎不用手写 SQL这对毕设开发速度的提升非常明显。它提供 BaseMapper 的通用方法条件构造器 Wrapper 也能覆盖 90% 的动态查询需求。MySQL 不用说关系型数据库里最适合做这种业务系统的选择。Redis 在这个项目里的定位有两个一是存验证码和 JWT 黑名单二是作为高并发挂号场景下的预扣减方案。如果觉得 Redis 环境配置麻烦至少要把验证码缓存这个场景用上否则后面答辩被问到“你项目里哪里用了 Redis”会很难看。前端如果用 Vue 3 Element Plus做后台管理页面会非常快市面上组件库现成的表格、表单、弹窗都能直接拿来用。如果你对前端不熟也可以退一步用 Thymeleaf 服务端渲染但我的建议是尽量做前后端分离——论文里可以多写一章 RESTful API 设计工作量真实又好看。2. 数据库建模与状态机设计问诊、挂号、处方三张核心表的来龙去脉2.1 核心表结构总览与通用字段在线问诊系统的数据库设计是整个项目的地基地基没打好后面写代码会到处补丁。核心表建议控制在 10 张以内太多会消耗你大量时间太少又撑不起一个完整的业务闭环。我按业务域把表划分成了四组用户域包含 user 表和 doctor_info 表诊疗域包含 schedule排班、visit_source号源、registration挂号单、consultation问诊单、prescription处方和 prescription_item处方明细交互域包含 message问诊消息基础数据域包含 department科室。所有表统一加上 id 主键、create_time、update_time、deleted 逻辑删除这四个通用字段。逻辑删除用 MyBatis-Plus 的 TableLogic 注解就能实现删除操作自动变成 update这在答辩阐述数据安全时是个小加分项。另外字段命名统一用下划线风格Java 实体类用驼峰MyBatis-Plus 会自动映射不要搞出字段命名混乱的“野路子”。2.2 号源表与排班设计为什么不用“总号数减已挂数”这是整个项目里最值得认真设计的表因为挂号业务本质上是资源分配问题。常见的错误做法是schedule 表里放 total_count 和 booked_count 两个字段挂号时先查总号数是否大于已挂数然后再 update booked_count 加 1。这个做法在并发请求下很容易超卖而且余号数据只能通过计算获得出了问题很难追溯。我的建议是采用“号源明细”模式排班表只描述“某个医生在某个时段出诊”号源表则把每个就诊时间段对应的号牌拆成独立记录。比如上午 8:30-9:00 这个排班产生 3 个号源记录每个号源记录有独立的 status 字段0 表示可挂1 表示已锁定2 表示已挂号3 表示已取消。这样每一笔挂号都有明确的资源对象“到底挂号成功没有”在数据层面一目了然。排班表核心字段包括 doctor_id、department_id、work_date、start_time、end_time、total_count、remain_count。号源表核心字段包括 schedule_id、source_no第几号、visit_time、status。挂号时先查某个号源记录状态再通过 update 语句加状态条件来更新可以在单行记录粒度上避免并发问题这个后面会详细展开。2.3 问诊单的状态机设计与不可跳转原则问诊单的状态机是整个系统业务逻辑的中枢神经。我的设计是五状态模型0 待支付、1 待接诊、2 问诊中、3 已完成、4 已取消。如果你不做支付模块可以直接从待接诊开始但保留待支付状态在论文里说明“预留支付扩展点”会更完整。状态流转的方向必须是可控的待支付可以取消待接诊可以由医生接诊变成问诊中问诊中可以被医生结束变成已完成问诊中时患者也能申请取消。但绝不允许出现类似“问诊中直接跳已完成又跳回待接诊”这种乱象。实现上很简单每个状态变更的 service 方法里先校验当前状态再执行 update 操作而不是直接在 SQL 里 update status。这样写会多几行代码但后期调试和答辩被追问时你会感谢自己。这里有一个实操心得状态不要用字符串存‘pending’、‘finished’这种英文单词直接用数字枚举值存入数据库Java 代码里定义枚举类。原因有两个一是数字占空间小二是前端展示时统一映射中文文案不会出现“代码里写的是 COMPLETED数据库里存的是 completed”这种低级乌龙。2.4 处方表设计为什么要拆成处方主表和明细表处方是问诊流程的结尾产物设计成一对多的两张表是基本常识。prescription 主表记录问诊单 id、医生 id、患者 id、诊断结论、开方时间prescription_item 明细表记录药品名称、规格、用法用量、数量。拆成两张表的原因很多最核心的是一张处方可能包含多种药如果每种药品的用法用量都属于不同的诊断目的将来做数据统计比如分析某类药品的开方频次时明细表能直接派上用场。不要图省事把药品信息塞到一个 text 字段里存 JSON这种设计虽然写起来爽但答辩老师一眼就能看出问题而且连“数据规范化”这道防线都没有。处方和诊断结论都属于敏感信息你的演示数据库里一定不要出现真实患者和真实医生信息用模拟数据就好这样既展示功能又不会有数据合规隐患。3. SpringBoot 工程落地项目结构、JWT 鉴权与问诊接口链路3.1 项目标准目录结构按业务模块分包还是按技术分层分包创建项目时我见过很多工程包里就一个 controller 文件夹里面堆了几十个类。虽然 SpringBoot 本身不强求包结构但毕设代码的包结构直接影响阅读体验和答辩印象。推荐的做法是顶层按技术分层controller、service、mapper、entity、dto、vo、config、common 这八个包然后在 service 包内部再按业务模块建子包。com.example.onlinedoctor ├── common # 统一返回结果、全局异常、常量、枚举 ├── config # SpringBoot 配置类、拦截器注册、跨域配置 ├── controller # REST 接口层 ├── dto # 请求参数对象 ├── vo # 响应视图对象 ├── entity # 数据库实体 ├── mapper # MyBatis-Plus 的 Mapper 接口 └── service # 业务逻辑层 ├── user ├── hospital ├── consultation └── message有一个特别注意点vo 和 dto 不要混为一谈。vo 是给前端展示用的响应数据比如医生信息里合并了科室名称dto 是接收前端传来的参数比如挂号请求里的排班 id、号源 id。很多入门开发把 entity 直接丢给前端返回会出现 JSON 里带着密码哈希、逻辑删除标记这种问题。在答辩时主动说一句“我用 vo 隔离了敏感字段”是一个很自然的加分点。3.2 JWT 鉴权从登录到接口访问的完整链路在线问诊系统有患者、医生、管理员三类角色接口权限必须控制但这不意味着要引入 Spring Security。Security 对毕设来说太重了自己写 JWT 过滤器加拦截器反而能把原理讲得更清楚。登录接口的逻辑是这样用户传账号密码后端校验成功后用 userId、role 等信息生成 token 返回给前端。前端在后续请求中把这个 token 放进请求头里一般是“Authorization: Bearer ”这种格式。后端通过一个 OncePerRequestFilter 拦截所有请求解析 token 并校验签名解析出的用户信息放入 ThreadLocal。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims ! null) { Long userId Long.parseLong(claims.get(userId).toString()); String role claims.get(role).toString(); UserContext.set(userId, role); } } chain.doFilter(request, response); } }解析失败只做放行处理让拦截器去判断哪些接口需要登录。这种设计比“解析失败直接返回 401”要灵活因为有些接口是公开的比如科室列表。再配合一个自定义的 RequireRole(PATIENT) 注解和 Spring 拦截器就能实现基于角色的接口访问控制。这套代码虽然基础但 JWT 无状态认证、过滤器链、自定义注解三个知识点覆盖得很完整很符合毕设的复杂度要求。有一个实际开发中的小坑JWT 过期时间不要设得太短。很多新手设成 30 分钟演示期间去倒杯水回来就过期了还要重新登录体验很差。我建议 access token 过期时间设为 2 小时答辩演示完全够用。如果你觉得这不够严谨论文里可以写一句“引入 refresh token 机制作为后续优化方向”既不增加代码量又显得你有扩展意识。3.3 问诊接口链路从发起问诊到医生开处方问诊模块是整个系统里接口最多的部分大概需要这些患者发起问诊POST /api/consultation、医生查看待接诊列表GET /api/consultation/pending、医生接诊PUT /api/consultation/{id}/accept、发送消息POST /api/message、医生结束问诊PUT /api/consultation/{id}/finish、医生开处方POST /api/prescription。这里用幂等性的例子来展示一下设计思考。患者发起问诊请求如果因为网络超时被重复提交就会创建出两条问诊单这在业务上是不可接受的。解决办法是在 consultation 表上给 patient_id 和 status 加唯一索引或者更直接一点在 service 层加一个基于 Redis 的 setNX 防重锁。每次发起问诊前先尝试加锁key 是“consultation:create:{patientId}”加锁成功才继续执行执行完释放锁。医生开处方时也要注意事务边界开完处方后问诊单状态要同步从“问诊中”改成“已完成”。这两个动作必须放在一个 Transactional 方法里否则可能出现“处方已经生成但问诊单还显示进行中”的脏数据状态。关于事务还有一个经典的坑同一个类内部 this.selfMethod() 调用另一个 Transactional 方法事务会失效。因为这个调用绕过了 Spring 生成的代理对象。这个小知识点很多工作一两年的开发都会踩你能写进项目里答辩时是很稳的。3.4 统一返回体与全局异常处理看似简单但绝对值得写我建议从第一天写接口就启用统一返回体 R 结构是 code、message、data 三个字段。code 为 0 表示成功非 0 表示业务错误配合一个 GlobalExceptionHandler 用 RestControllerAdvice 捕获异常。这样做的好处是整个前端调接口的逻辑可以统一不需要每个接口单独做错误处理。业务异常直接抛一个带错误码的 BizException全局异常处理器捕获后返回给前端。这个模式虽然在三行代码的 demo 里看起来繁琐但在一个几十个接口的项目里能帮你省下大量的重复代码。更重要的是在论文中“统一异常处理”是可以单独拿出来的一个技术点很多同学的论文里只有 CRUD没有异常设计意识这一点就能让你的项目拉开差距。4. 号源并发控制实战从超卖事故到行锁与乐观锁的取舍4.1 最直觉的写法为什么一定会出问题挂号并发的残酷性只有亲手测过才懂。很多学生写挂号的逻辑是查号源状态再做判断流程如下VisitSource source visitSourceMapper.selectById(sourceId); if (source.getStatus() 0) { source.setStatus(2); visitSourceMapper.updateById(source); return 挂号成功; } return 号源已被占用;这种 check-then-act 写法也就是先检查再执行在单线程下完全没问题但一旦并发超过一定量级两个请求可能同时查到 status0然后都执行 update结果就是同一个号源被挂给两个患者也就是超卖。本质原因在于检查和更新两个操作不是一个原子操作中间存在时间窗口。理解这个问题不需要背概念只要想明白一个场景挂号系统在放号的瞬间几百个人同时点击挂号按钮数据库层面的行为是很多请求几乎同时到达。你的代码如果分成了两步执行第一步查询的时候大家都查到了“还有号”第二步更新的时候大家一起改数据库不会替你自动判断“只能有一个成功”。数据库能保证的是单条 update 语句内部的原子性但不会自动约束你“先查再改”的整个业务逻辑。4.2 方案一数据库行锁 SELECT FOR UPDATE可靠性优先最简单的修复方式是给查询加 for update 行锁。用 MySQL 的机制把被选中的行锁住让其他事务等待直到当前事务提交或回滚才释放。Transactional public void register(Long sourceId, Long patientId) { VisitSource source visitSourceMapper.selectByIdForUpdate(sourceId); if (source.getStatus() ! 0) { throw new BizException(号源已被占用); } source.setStatus(2); source.setPatientId(patientId); visitSourceMapper.updateById(source); }selectByIdForUpdate 对应 SQLSELECT * FROM visit_source WHERE id ? FOR UPDATE。这种方式把并发问题交给数据库可靠性很高代码也简单。但它有一个必须注意的代价for update 期间该行记录上的其他事务都会阻塞。所以事务里绝对不要做多余的事情尤其不要把网络调用、短信通知这类耗时的操作放进事务里否则并发能力会急剧下降很可能拖垮整个库。这个方案适合毕设场景直接使用因为你只有一台数据库性能瓶颈不是你需要担心的事。答辩时你能把这个方案的原理讲清楚说一句“通过悲观锁保护共享资源的修改安全”已经是今年毕设里相当不错的程度了。4.3 方案二乐观锁 version 字段代码侵入小性能更好如果你不想用 for update 那么重的锁还有一个更优雅的思路在号源表加一个 version 字段更新时带着版本号做条件。UPDATE visit_source SET status 2, patient_id #{patientId}, version version 1 WHERE id #{id} AND version #{oldVersion} AND status 0如果执行这条 SQL 的影响行数为 1说明更新成功号源归这个患者了如果影响行数为 0说明该记录在操作期间被别的事务改过了这次挂号失败前端直接提示“手慢了号被抢了”。乐观锁的精髓在于“假设冲突不常发生只在更新时校验版本号”所以它没有数据库行锁那么强的阻塞代价但它的缺点是不能解决“ABA 问题”也不适用于高冲突场景。在号源这种资源本身就很稀缺的场景悲观锁和乐观锁都能用。我个人建议毕设用方案一把方案二放在论文的“方案对比”章节里充分展示你的技术选型能力。4.4 为什么 Redis 预扣减是加分项但不要强行用如果你还想再往前一步可以考虑用 Redis 做预扣减方案。核心理念是把挂号请求改成先到 Redis 里做库存扣减扣减成功了再写数据库避免大量请求同时打在数据库上。Redis 单线程处理命令天然是原子的配合 Lua 脚本可以保证“检查库存并扣减”的原子性比数据库行锁又少了一层瓶颈。不过我要诚实地说毕设项目里没有那么多并发流量Redis 预扣减方案引入的复杂度可能大过收益——你又得处理 Redis 与数据库的一致性、库存回补、消息队列做异步落库这已经是一个生产级系统的规模了。我的建议是你能在论文里把这个方案的思路写出来答辩时说明白“如果系统上线我会用 Redis 做流量削峰”就足够展示知识的广度了代码里还是用行锁或乐观锁最稳妥。4.5 实测验证用 JMeter 复现超卖现象这一节值得你花几个小时亲手做一遍。用 JMeter 起一个线程组模拟 100 个并发线程同时请求同一个号源的挂号接口因为初始状态号源数量有限所以能清楚地看到两种结果一种是超卖数据一组 SQL 查出来同一号源被多个患者拥有另一种是正确数据部分请求成功其余请求收到“号源已被占用”提示。实际测过你才会发现几个隐藏问题事务没生效时超卖照样存在for update 命中的索引不对导致锁的范围变大接口没有做幂等导致同一患者重复挂号。这些问题如果只在写代码阶段是发现不了的。把这些实测截图放进论文里再配上修复前后的对比能让你的项目真实感和专业度提升很多。5. 医患交互模块怎么做消息表与已读未读的两种实现路径5.1 消息表设计为什么按问诊单维度组织消息在线问诊里患者和医生之间的沟通是围绕问诊单进行的所以消息应该挂在 consultation_id 下面不需要引入群聊或独立会话的概念。消息表核心字段是 id、consultation_id、from_user_id、to_user_id、content、type、is_read、create_time。type 可以区分文字、图片、系统通知图片可以用一行大字段存 URL 地址。这里一个容易忽略的需求是患者发起问诊后医生应该能收到“有新问诊待处理”的通知患者给医生发消息时医生首页能看到未读数的变化。我的做法是既不单独建通知表也不做复杂的消息队列而是在查询医生问诊单列表时聚合出每条问诊单的未读消息数量列表页上显示一个红色数字即可。这种聚合查询用一条带 count 的关联 SQL 加 group by 就能实现对毕设来说简单有效。5.2 方案 A前端轮询拉取新消息推荐首选问诊过程中最核心的需求是“我发出消息之后对方能尽快看到”。前后端分离场景下最简单的做法是前端定时轮询接口例如每 3 秒请求一次拉取该问诊单的最新消息列表。setInterval(() { loadMessages(consultationId, lastMessageId); }, 3000);增量拉取的关键在于带上 lastMessageId只返回 id 大于这个值的消息。这个简单设计能显著减少每次轮询的响应体大小。秒级轮询对一台 MySQL 来说毫无压力哪怕整个系统只有一个问诊订单在演示体验也足够流畅。选择轮询而不直接上 WebSocket 的真实原因是轮询没有状态不需要维护连接不会因为服务器重启导致连接失效更不用考虑鉴权握手怎么传 token。毕设答辩场景下稳定性压倒一切“轮询虽然实时性有秒级延迟但对图文问诊场景已经足够”——这句话你写在论文里就是一次很成熟的工程权衡。5.3 方案 BWebSocket 点对点推送加分扩展如果你项目想体现更强的技术深度可以在轮询之外另起一个 WebSocket 模块但一开始就要清楚它的坑点。最直接的坑是认证问题WebSocket 握手时不方便加自定义 Header常见解法是把 token 作为 query 参数传过去在握手拦截器中校验。第二个坑是关联问题服务端需要维护 MapuserId, Session 的映射用户下线时还要防止 Session 泄漏。第二个坑是集群问题如果部署了多台服务器WebSocket 连接只和当前机器绑定用户通过机器 A 连上 WebSocket但机器 B 处理了消息推送逻辑就读不到用户的 Session。生产环境要用 Redis Pub/Sub 或者消息队列转发对毕设来说不建议碰集群。如果你想加这个扩展最好的方式是单独写一个模块不影响主流程稳定。5.4 已读未读一个时间字段就能解决绝大多数情况已读未读的简单设计是在问诊单表里加一个 patient_last_read_time 和 doctor_last_read_time记录每一方最后一次查看消息列表的时间。查询未读消息数时统计 create_time 大于对方 last_read_time 的消息数量即可。更严格的方案是建一张 message_read_record 表每条消息的已读状态独立记录但这是针对“每条消息都要显示已读详情”的 IM 场景图文问诊根本不需要。你可以这样写患者和医生只能看到自己这边“未读消息条数”的数字点进去列表之后未读数字清零。用时间字段一次性更新比维护一张明细表要省太多工作量。这个模块里我踩过的坑是前端后端使用的时区不一致导致时间比较错乱。China Standard Time 和 UTC 差了 8 个小时秒级差距都能导致未读数字一直不清零。解决办法很简单统一在 SpringBoot 配置里指定 Jackson 的时区为 GMT8后端的时间存取都用 LocalDateTime数据库 JDBC 连接串里加上 serverTimezoneAsia/Shanghai。这个细节修复之后消息系统的体验会立刻正常。6. 答辩前必须能对答如流的十个高频追问6.1 从“为什么选 SpringBoot”到“项目难点在哪”答辩环节老师们不会拿着你的代码逐行看他们最关心的是“这个项目是不是你写的”以及“你对自己做的事情有没有理解”。我整理过一份高频追问清单这些问题几乎每年都会出现在在线问诊、挂号系统这类题目的答辩现场。高频问题答题要点为什么用 SpringBoot 而不用 SSM自动配置简化繁琐 bean 配置、starter 聚合依赖、内嵌容器本质仍是 Spring MVC 那一套别答成“新框架碾压旧框架”JWT 和 Session 有什么区别JWT 无状态、跨域友好但服务端无法主动失效只能等过期。项目里配合 Redis 黑名单解决退出登录问题挂号超卖怎么解决的从 check-then-act 的原子性缺陷说起对比数据库行锁和乐观锁说明线上会用 Redis 预扣减削峰事务失效有哪些场景同类自调用、异常被 catch 没抛出运行时异常、方法不是 public、数据库引擎不支持事务MyBatis-Plus 与 MyBatis 区别通用 CRUD 免写 SQL、Wrapper 条件构造器、分页插件底层还是 MyBatis 的代理机制接口幂等怎么保证唯一索引 唯一业务单号 / Redis setNX 防重锁 / 状态机前置校验数据库索引怎么设计的外键建索引、高频查询条件建索引号源表状态机里唯一索引 (schedule_id, source_no)多个用户抢同一个号源怎么办悲观锁、乐观锁、Redis 原子扣减三种方案对比核心是避免 check-then-act项目里用过哪些设计模式模板方法定通用流程、策略模式处理不同类型消息、工厂模式创建单据、观察者事件解耦项目里哪些地方用了 Redis验证码存储、JWT 黑名单、可选的消息推送 pub/sub6.2 论文和技术要点要能对上号有一个很关键的建议不要为了追求高级就写你项目里没实现的技术。很多学生论文里写了 Redis 分布式锁但代码里根本没有对应的实现答辩老师追问两个细节就会露馅。你的原则是“每写一个技术名词就能在代码里指出用在哪一行”哪怕技术本身不深也比纸上谈兵强。在线问诊系统这个题目的一个好处是业务里天然有状态机问诊单状态、并发控制号源挂号、权限体系三类角色、主从扩展性问诊消息这些能拿出来讲的话题。你只要把每个技术点和业务模块对应好答辩时基本不会被难住。6.3 演示时最容易翻车的前置检查最后一个建议无关代码纯粹来自我见过的大量现场事故。答辩演示前检查以下事项系统是否用固定账号登录而不是临时注册注意演示前把测试账号密码写在纸上演示环境是否有网前端依赖 CDN 的框架需要提前处理数据库里的模拟数据是否足够真实包括科室、医生排班、历史问诊记录都要有而不是一张空表展示“暂无数据”。特别是排班数据一定要提前造好最近两天的数据很多同学的排班表只造了昨天的记录演示时选择了科室却发现没有号源可挂场面非常尴尬。造数的时候可以批量生成未来一周的排班和号源每个医生排班生成 5 到 10 个号源记录这不仅方便演示也方便你自己并发测试。关于做毕设的一点个人体会做完这个项目再回头看我最大的感受是毕设不是越难越好而是“能在规定时间做完还能讲清楚”才有意义。在线问诊系统这个题目最难得的地方是它业务完整又不过度复杂技术栈覆盖了 Java Web 开发的核心面。我自己的操作习惯是先把挂号到问诊到开处方这条核心链路用最简单的 CRUD 跑通再去加 Redis、JWT、并发控制这些加分项。这样就算时间不够你手里也有一个完整能跑的项目而不是一堆半成品模块。最后提醒一句所有的演示数据一定要自己模拟生成不要在系统里出现任何真实个人信息这既是做开发的底线也是对自己负责。 SpringBoot在线问诊系统毕设：从数据库到并发控制实战
每年到了毕设季Java 方向的同学问得最多的问题就是“做什么题目”。选电商系统太腻选管理系统太水选算法类又怕自己啃不动。如果你正在这个阶段纠结我建议认真看一眼在线问诊系统这个方向——它用 SpringBoot 做后端、走 Java Web 技术栈既能体现业务建模能力又有并发控制、状态机、权限认证这些可深挖的技术点工作量也刚好卡在“一个人能做完”的范围内。这篇博文不打算只给你一份功能清单而是把从选题、建模、编码到答辩的完整思路讲透适合准备做毕设的学生也适合刚入门 SpringBoot 想找个完整项目练手的人。1. 为什么这个题目值得做角色划分、功能矩阵与技术栈取舍1.1 先想清楚系统边界核心闭环、可选延展、明确不做我见过太多学生拿到题目就开始写代码结果写了一个月发现功能越加越多数据库改了十几版最后论文都编不下去。在线问诊系统这个题目最理想的做法是先把自己围在一个能跑通的核心闭环里。核心闭环就是用户注册登录 → 选择科室和医生 → 查看排班 → 在线挂号 → 发起图文问诊 → 医生回复 → 医生开处方 → 患者查看处方并结束问诊。能把这个链路完整跑通你的毕设已经及格了。在这个基础上可以延展的功能包括科室管理、医生排班管理、患者健康档案、历史问诊记录、管理员数据统计、公告和消息通知。这些属于“加分项”在核心链路完成之后逐个加上去不会伤筋动骨。更要命的是要明确“哪些不做”。很多同学一上来就想接入在线支付、视频问诊、电子病历互联互通这些功能会把你的项目带进深渊。在线支付涉及第三方对接和资质视频问诊需要 WebRTC 或第三方 SDK不是在一个毕设周期能打磨好的。你要在论文里写清楚这个系统的边界这反而会让答辩老师觉得你设计思路清晰。1.2 三类角色的权限划分与功能矩阵在线问诊系统最常见的角色划分是三类患者、医生、管理员。权限设计不宜搞得太复杂用一张角色表加上接口层面的角色校验就能搞定但是功能矩阵必须想清楚。患者端功能注册登录、浏览科室和医生列表、查看医生排班、在线挂号、发起问诊、查看问诊记录与处方、个人资料维护。医生端功能查看排班、处理待接诊的问诊单、回复患者消息、结束问诊、开具处方、查看历史接诊记录。管理员端功能审核医生信息、管理科室、管理排班数据、查看系统统计数据。这里有个容易忽略的细节医生不是平台自己的员工而是“入驻”的。所以医生需要有一个入驻申请和管理员审核的流程哪怕你只是用一个 status 字段从 0 改成 1也比你写死一个医生账号要专业得多。这个流程在论文里能写成“平台准入机制”一下子就有了业务深度。1.3 技术栈选型为什么是 SpringBoot MyBatis-Plus MySQL Redis很多同学的选题本身没问题但技术栈选得让人捏把汗。如果是纯 Java Web 方向的毕设我强烈建议后端用 SpringBoot前端用 Vue 做前后端分离数据库用 MySQL缓存用 RedisORM 用 MyBatis-Plus。为什么不用传统的 SSM 加 JSP不是说 SSM 不能做而是 SpringBoot 已经是这个时代 Java Web 开发的默认起点。它通过 starter 机制把依赖管理简化了内嵌 Tomcat 让你不用再部署 war 包这些特性可以让你把精力放到业务上而不是配置文件里。论文的对比章节也更好写SpringBoot 的自动配置、约定优于配置、生态成熟度都是现成的素材。MyBatis-Plus 的价值在于单表 CRUD 几乎不用手写 SQL这对毕设开发速度的提升非常明显。它提供 BaseMapper 的通用方法条件构造器 Wrapper 也能覆盖 90% 的动态查询需求。MySQL 不用说关系型数据库里最适合做这种业务系统的选择。Redis 在这个项目里的定位有两个一是存验证码和 JWT 黑名单二是作为高并发挂号场景下的预扣减方案。如果觉得 Redis 环境配置麻烦至少要把验证码缓存这个场景用上否则后面答辩被问到“你项目里哪里用了 Redis”会很难看。前端如果用 Vue 3 Element Plus做后台管理页面会非常快市面上组件库现成的表格、表单、弹窗都能直接拿来用。如果你对前端不熟也可以退一步用 Thymeleaf 服务端渲染但我的建议是尽量做前后端分离——论文里可以多写一章 RESTful API 设计工作量真实又好看。2. 数据库建模与状态机设计问诊、挂号、处方三张核心表的来龙去脉2.1 核心表结构总览与通用字段在线问诊系统的数据库设计是整个项目的地基地基没打好后面写代码会到处补丁。核心表建议控制在 10 张以内太多会消耗你大量时间太少又撑不起一个完整的业务闭环。我按业务域把表划分成了四组用户域包含 user 表和 doctor_info 表诊疗域包含 schedule排班、visit_source号源、registration挂号单、consultation问诊单、prescription处方和 prescription_item处方明细交互域包含 message问诊消息基础数据域包含 department科室。所有表统一加上 id 主键、create_time、update_time、deleted 逻辑删除这四个通用字段。逻辑删除用 MyBatis-Plus 的 TableLogic 注解就能实现删除操作自动变成 update这在答辩阐述数据安全时是个小加分项。另外字段命名统一用下划线风格Java 实体类用驼峰MyBatis-Plus 会自动映射不要搞出字段命名混乱的“野路子”。2.2 号源表与排班设计为什么不用“总号数减已挂数”这是整个项目里最值得认真设计的表因为挂号业务本质上是资源分配问题。常见的错误做法是schedule 表里放 total_count 和 booked_count 两个字段挂号时先查总号数是否大于已挂数然后再 update booked_count 加 1。这个做法在并发请求下很容易超卖而且余号数据只能通过计算获得出了问题很难追溯。我的建议是采用“号源明细”模式排班表只描述“某个医生在某个时段出诊”号源表则把每个就诊时间段对应的号牌拆成独立记录。比如上午 8:30-9:00 这个排班产生 3 个号源记录每个号源记录有独立的 status 字段0 表示可挂1 表示已锁定2 表示已挂号3 表示已取消。这样每一笔挂号都有明确的资源对象“到底挂号成功没有”在数据层面一目了然。排班表核心字段包括 doctor_id、department_id、work_date、start_time、end_time、total_count、remain_count。号源表核心字段包括 schedule_id、source_no第几号、visit_time、status。挂号时先查某个号源记录状态再通过 update 语句加状态条件来更新可以在单行记录粒度上避免并发问题这个后面会详细展开。2.3 问诊单的状态机设计与不可跳转原则问诊单的状态机是整个系统业务逻辑的中枢神经。我的设计是五状态模型0 待支付、1 待接诊、2 问诊中、3 已完成、4 已取消。如果你不做支付模块可以直接从待接诊开始但保留待支付状态在论文里说明“预留支付扩展点”会更完整。状态流转的方向必须是可控的待支付可以取消待接诊可以由医生接诊变成问诊中问诊中可以被医生结束变成已完成问诊中时患者也能申请取消。但绝不允许出现类似“问诊中直接跳已完成又跳回待接诊”这种乱象。实现上很简单每个状态变更的 service 方法里先校验当前状态再执行 update 操作而不是直接在 SQL 里 update status。这样写会多几行代码但后期调试和答辩被追问时你会感谢自己。这里有一个实操心得状态不要用字符串存‘pending’、‘finished’这种英文单词直接用数字枚举值存入数据库Java 代码里定义枚举类。原因有两个一是数字占空间小二是前端展示时统一映射中文文案不会出现“代码里写的是 COMPLETED数据库里存的是 completed”这种低级乌龙。2.4 处方表设计为什么要拆成处方主表和明细表处方是问诊流程的结尾产物设计成一对多的两张表是基本常识。prescription 主表记录问诊单 id、医生 id、患者 id、诊断结论、开方时间prescription_item 明细表记录药品名称、规格、用法用量、数量。拆成两张表的原因很多最核心的是一张处方可能包含多种药如果每种药品的用法用量都属于不同的诊断目的将来做数据统计比如分析某类药品的开方频次时明细表能直接派上用场。不要图省事把药品信息塞到一个 text 字段里存 JSON这种设计虽然写起来爽但答辩老师一眼就能看出问题而且连“数据规范化”这道防线都没有。处方和诊断结论都属于敏感信息你的演示数据库里一定不要出现真实患者和真实医生信息用模拟数据就好这样既展示功能又不会有数据合规隐患。3. SpringBoot 工程落地项目结构、JWT 鉴权与问诊接口链路3.1 项目标准目录结构按业务模块分包还是按技术分层分包创建项目时我见过很多工程包里就一个 controller 文件夹里面堆了几十个类。虽然 SpringBoot 本身不强求包结构但毕设代码的包结构直接影响阅读体验和答辩印象。推荐的做法是顶层按技术分层controller、service、mapper、entity、dto、vo、config、common 这八个包然后在 service 包内部再按业务模块建子包。com.example.onlinedoctor ├── common # 统一返回结果、全局异常、常量、枚举 ├── config # SpringBoot 配置类、拦截器注册、跨域配置 ├── controller # REST 接口层 ├── dto # 请求参数对象 ├── vo # 响应视图对象 ├── entity # 数据库实体 ├── mapper # MyBatis-Plus 的 Mapper 接口 └── service # 业务逻辑层 ├── user ├── hospital ├── consultation └── message有一个特别注意点vo 和 dto 不要混为一谈。vo 是给前端展示用的响应数据比如医生信息里合并了科室名称dto 是接收前端传来的参数比如挂号请求里的排班 id、号源 id。很多入门开发把 entity 直接丢给前端返回会出现 JSON 里带着密码哈希、逻辑删除标记这种问题。在答辩时主动说一句“我用 vo 隔离了敏感字段”是一个很自然的加分点。3.2 JWT 鉴权从登录到接口访问的完整链路在线问诊系统有患者、医生、管理员三类角色接口权限必须控制但这不意味着要引入 Spring Security。Security 对毕设来说太重了自己写 JWT 过滤器加拦截器反而能把原理讲得更清楚。登录接口的逻辑是这样用户传账号密码后端校验成功后用 userId、role 等信息生成 token 返回给前端。前端在后续请求中把这个 token 放进请求头里一般是“Authorization: Bearer ”这种格式。后端通过一个 OncePerRequestFilter 拦截所有请求解析 token 并校验签名解析出的用户信息放入 ThreadLocal。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims ! null) { Long userId Long.parseLong(claims.get(userId).toString()); String role claims.get(role).toString(); UserContext.set(userId, role); } } chain.doFilter(request, response); } }解析失败只做放行处理让拦截器去判断哪些接口需要登录。这种设计比“解析失败直接返回 401”要灵活因为有些接口是公开的比如科室列表。再配合一个自定义的 RequireRole(PATIENT) 注解和 Spring 拦截器就能实现基于角色的接口访问控制。这套代码虽然基础但 JWT 无状态认证、过滤器链、自定义注解三个知识点覆盖得很完整很符合毕设的复杂度要求。有一个实际开发中的小坑JWT 过期时间不要设得太短。很多新手设成 30 分钟演示期间去倒杯水回来就过期了还要重新登录体验很差。我建议 access token 过期时间设为 2 小时答辩演示完全够用。如果你觉得这不够严谨论文里可以写一句“引入 refresh token 机制作为后续优化方向”既不增加代码量又显得你有扩展意识。3.3 问诊接口链路从发起问诊到医生开处方问诊模块是整个系统里接口最多的部分大概需要这些患者发起问诊POST /api/consultation、医生查看待接诊列表GET /api/consultation/pending、医生接诊PUT /api/consultation/{id}/accept、发送消息POST /api/message、医生结束问诊PUT /api/consultation/{id}/finish、医生开处方POST /api/prescription。这里用幂等性的例子来展示一下设计思考。患者发起问诊请求如果因为网络超时被重复提交就会创建出两条问诊单这在业务上是不可接受的。解决办法是在 consultation 表上给 patient_id 和 status 加唯一索引或者更直接一点在 service 层加一个基于 Redis 的 setNX 防重锁。每次发起问诊前先尝试加锁key 是“consultation:create:{patientId}”加锁成功才继续执行执行完释放锁。医生开处方时也要注意事务边界开完处方后问诊单状态要同步从“问诊中”改成“已完成”。这两个动作必须放在一个 Transactional 方法里否则可能出现“处方已经生成但问诊单还显示进行中”的脏数据状态。关于事务还有一个经典的坑同一个类内部 this.selfMethod() 调用另一个 Transactional 方法事务会失效。因为这个调用绕过了 Spring 生成的代理对象。这个小知识点很多工作一两年的开发都会踩你能写进项目里答辩时是很稳的。3.4 统一返回体与全局异常处理看似简单但绝对值得写我建议从第一天写接口就启用统一返回体 R 结构是 code、message、data 三个字段。code 为 0 表示成功非 0 表示业务错误配合一个 GlobalExceptionHandler 用 RestControllerAdvice 捕获异常。这样做的好处是整个前端调接口的逻辑可以统一不需要每个接口单独做错误处理。业务异常直接抛一个带错误码的 BizException全局异常处理器捕获后返回给前端。这个模式虽然在三行代码的 demo 里看起来繁琐但在一个几十个接口的项目里能帮你省下大量的重复代码。更重要的是在论文中“统一异常处理”是可以单独拿出来的一个技术点很多同学的论文里只有 CRUD没有异常设计意识这一点就能让你的项目拉开差距。4. 号源并发控制实战从超卖事故到行锁与乐观锁的取舍4.1 最直觉的写法为什么一定会出问题挂号并发的残酷性只有亲手测过才懂。很多学生写挂号的逻辑是查号源状态再做判断流程如下VisitSource source visitSourceMapper.selectById(sourceId); if (source.getStatus() 0) { source.setStatus(2); visitSourceMapper.updateById(source); return 挂号成功; } return 号源已被占用;这种 check-then-act 写法也就是先检查再执行在单线程下完全没问题但一旦并发超过一定量级两个请求可能同时查到 status0然后都执行 update结果就是同一个号源被挂给两个患者也就是超卖。本质原因在于检查和更新两个操作不是一个原子操作中间存在时间窗口。理解这个问题不需要背概念只要想明白一个场景挂号系统在放号的瞬间几百个人同时点击挂号按钮数据库层面的行为是很多请求几乎同时到达。你的代码如果分成了两步执行第一步查询的时候大家都查到了“还有号”第二步更新的时候大家一起改数据库不会替你自动判断“只能有一个成功”。数据库能保证的是单条 update 语句内部的原子性但不会自动约束你“先查再改”的整个业务逻辑。4.2 方案一数据库行锁 SELECT FOR UPDATE可靠性优先最简单的修复方式是给查询加 for update 行锁。用 MySQL 的机制把被选中的行锁住让其他事务等待直到当前事务提交或回滚才释放。Transactional public void register(Long sourceId, Long patientId) { VisitSource source visitSourceMapper.selectByIdForUpdate(sourceId); if (source.getStatus() ! 0) { throw new BizException(号源已被占用); } source.setStatus(2); source.setPatientId(patientId); visitSourceMapper.updateById(source); }selectByIdForUpdate 对应 SQLSELECT * FROM visit_source WHERE id ? FOR UPDATE。这种方式把并发问题交给数据库可靠性很高代码也简单。但它有一个必须注意的代价for update 期间该行记录上的其他事务都会阻塞。所以事务里绝对不要做多余的事情尤其不要把网络调用、短信通知这类耗时的操作放进事务里否则并发能力会急剧下降很可能拖垮整个库。这个方案适合毕设场景直接使用因为你只有一台数据库性能瓶颈不是你需要担心的事。答辩时你能把这个方案的原理讲清楚说一句“通过悲观锁保护共享资源的修改安全”已经是今年毕设里相当不错的程度了。4.3 方案二乐观锁 version 字段代码侵入小性能更好如果你不想用 for update 那么重的锁还有一个更优雅的思路在号源表加一个 version 字段更新时带着版本号做条件。UPDATE visit_source SET status 2, patient_id #{patientId}, version version 1 WHERE id #{id} AND version #{oldVersion} AND status 0如果执行这条 SQL 的影响行数为 1说明更新成功号源归这个患者了如果影响行数为 0说明该记录在操作期间被别的事务改过了这次挂号失败前端直接提示“手慢了号被抢了”。乐观锁的精髓在于“假设冲突不常发生只在更新时校验版本号”所以它没有数据库行锁那么强的阻塞代价但它的缺点是不能解决“ABA 问题”也不适用于高冲突场景。在号源这种资源本身就很稀缺的场景悲观锁和乐观锁都能用。我个人建议毕设用方案一把方案二放在论文的“方案对比”章节里充分展示你的技术选型能力。4.4 为什么 Redis 预扣减是加分项但不要强行用如果你还想再往前一步可以考虑用 Redis 做预扣减方案。核心理念是把挂号请求改成先到 Redis 里做库存扣减扣减成功了再写数据库避免大量请求同时打在数据库上。Redis 单线程处理命令天然是原子的配合 Lua 脚本可以保证“检查库存并扣减”的原子性比数据库行锁又少了一层瓶颈。不过我要诚实地说毕设项目里没有那么多并发流量Redis 预扣减方案引入的复杂度可能大过收益——你又得处理 Redis 与数据库的一致性、库存回补、消息队列做异步落库这已经是一个生产级系统的规模了。我的建议是你能在论文里把这个方案的思路写出来答辩时说明白“如果系统上线我会用 Redis 做流量削峰”就足够展示知识的广度了代码里还是用行锁或乐观锁最稳妥。4.5 实测验证用 JMeter 复现超卖现象这一节值得你花几个小时亲手做一遍。用 JMeter 起一个线程组模拟 100 个并发线程同时请求同一个号源的挂号接口因为初始状态号源数量有限所以能清楚地看到两种结果一种是超卖数据一组 SQL 查出来同一号源被多个患者拥有另一种是正确数据部分请求成功其余请求收到“号源已被占用”提示。实际测过你才会发现几个隐藏问题事务没生效时超卖照样存在for update 命中的索引不对导致锁的范围变大接口没有做幂等导致同一患者重复挂号。这些问题如果只在写代码阶段是发现不了的。把这些实测截图放进论文里再配上修复前后的对比能让你的项目真实感和专业度提升很多。5. 医患交互模块怎么做消息表与已读未读的两种实现路径5.1 消息表设计为什么按问诊单维度组织消息在线问诊里患者和医生之间的沟通是围绕问诊单进行的所以消息应该挂在 consultation_id 下面不需要引入群聊或独立会话的概念。消息表核心字段是 id、consultation_id、from_user_id、to_user_id、content、type、is_read、create_time。type 可以区分文字、图片、系统通知图片可以用一行大字段存 URL 地址。这里一个容易忽略的需求是患者发起问诊后医生应该能收到“有新问诊待处理”的通知患者给医生发消息时医生首页能看到未读数的变化。我的做法是既不单独建通知表也不做复杂的消息队列而是在查询医生问诊单列表时聚合出每条问诊单的未读消息数量列表页上显示一个红色数字即可。这种聚合查询用一条带 count 的关联 SQL 加 group by 就能实现对毕设来说简单有效。5.2 方案 A前端轮询拉取新消息推荐首选问诊过程中最核心的需求是“我发出消息之后对方能尽快看到”。前后端分离场景下最简单的做法是前端定时轮询接口例如每 3 秒请求一次拉取该问诊单的最新消息列表。setInterval(() { loadMessages(consultationId, lastMessageId); }, 3000);增量拉取的关键在于带上 lastMessageId只返回 id 大于这个值的消息。这个简单设计能显著减少每次轮询的响应体大小。秒级轮询对一台 MySQL 来说毫无压力哪怕整个系统只有一个问诊订单在演示体验也足够流畅。选择轮询而不直接上 WebSocket 的真实原因是轮询没有状态不需要维护连接不会因为服务器重启导致连接失效更不用考虑鉴权握手怎么传 token。毕设答辩场景下稳定性压倒一切“轮询虽然实时性有秒级延迟但对图文问诊场景已经足够”——这句话你写在论文里就是一次很成熟的工程权衡。5.3 方案 BWebSocket 点对点推送加分扩展如果你项目想体现更强的技术深度可以在轮询之外另起一个 WebSocket 模块但一开始就要清楚它的坑点。最直接的坑是认证问题WebSocket 握手时不方便加自定义 Header常见解法是把 token 作为 query 参数传过去在握手拦截器中校验。第二个坑是关联问题服务端需要维护 MapuserId, Session 的映射用户下线时还要防止 Session 泄漏。第二个坑是集群问题如果部署了多台服务器WebSocket 连接只和当前机器绑定用户通过机器 A 连上 WebSocket但机器 B 处理了消息推送逻辑就读不到用户的 Session。生产环境要用 Redis Pub/Sub 或者消息队列转发对毕设来说不建议碰集群。如果你想加这个扩展最好的方式是单独写一个模块不影响主流程稳定。5.4 已读未读一个时间字段就能解决绝大多数情况已读未读的简单设计是在问诊单表里加一个 patient_last_read_time 和 doctor_last_read_time记录每一方最后一次查看消息列表的时间。查询未读消息数时统计 create_time 大于对方 last_read_time 的消息数量即可。更严格的方案是建一张 message_read_record 表每条消息的已读状态独立记录但这是针对“每条消息都要显示已读详情”的 IM 场景图文问诊根本不需要。你可以这样写患者和医生只能看到自己这边“未读消息条数”的数字点进去列表之后未读数字清零。用时间字段一次性更新比维护一张明细表要省太多工作量。这个模块里我踩过的坑是前端后端使用的时区不一致导致时间比较错乱。China Standard Time 和 UTC 差了 8 个小时秒级差距都能导致未读数字一直不清零。解决办法很简单统一在 SpringBoot 配置里指定 Jackson 的时区为 GMT8后端的时间存取都用 LocalDateTime数据库 JDBC 连接串里加上 serverTimezoneAsia/Shanghai。这个细节修复之后消息系统的体验会立刻正常。6. 答辩前必须能对答如流的十个高频追问6.1 从“为什么选 SpringBoot”到“项目难点在哪”答辩环节老师们不会拿着你的代码逐行看他们最关心的是“这个项目是不是你写的”以及“你对自己做的事情有没有理解”。我整理过一份高频追问清单这些问题几乎每年都会出现在在线问诊、挂号系统这类题目的答辩现场。高频问题答题要点为什么用 SpringBoot 而不用 SSM自动配置简化繁琐 bean 配置、starter 聚合依赖、内嵌容器本质仍是 Spring MVC 那一套别答成“新框架碾压旧框架”JWT 和 Session 有什么区别JWT 无状态、跨域友好但服务端无法主动失效只能等过期。项目里配合 Redis 黑名单解决退出登录问题挂号超卖怎么解决的从 check-then-act 的原子性缺陷说起对比数据库行锁和乐观锁说明线上会用 Redis 预扣减削峰事务失效有哪些场景同类自调用、异常被 catch 没抛出运行时异常、方法不是 public、数据库引擎不支持事务MyBatis-Plus 与 MyBatis 区别通用 CRUD 免写 SQL、Wrapper 条件构造器、分页插件底层还是 MyBatis 的代理机制接口幂等怎么保证唯一索引 唯一业务单号 / Redis setNX 防重锁 / 状态机前置校验数据库索引怎么设计的外键建索引、高频查询条件建索引号源表状态机里唯一索引 (schedule_id, source_no)多个用户抢同一个号源怎么办悲观锁、乐观锁、Redis 原子扣减三种方案对比核心是避免 check-then-act项目里用过哪些设计模式模板方法定通用流程、策略模式处理不同类型消息、工厂模式创建单据、观察者事件解耦项目里哪些地方用了 Redis验证码存储、JWT 黑名单、可选的消息推送 pub/sub6.2 论文和技术要点要能对上号有一个很关键的建议不要为了追求高级就写你项目里没实现的技术。很多学生论文里写了 Redis 分布式锁但代码里根本没有对应的实现答辩老师追问两个细节就会露馅。你的原则是“每写一个技术名词就能在代码里指出用在哪一行”哪怕技术本身不深也比纸上谈兵强。在线问诊系统这个题目的一个好处是业务里天然有状态机问诊单状态、并发控制号源挂号、权限体系三类角色、主从扩展性问诊消息这些能拿出来讲的话题。你只要把每个技术点和业务模块对应好答辩时基本不会被难住。6.3 演示时最容易翻车的前置检查最后一个建议无关代码纯粹来自我见过的大量现场事故。答辩演示前检查以下事项系统是否用固定账号登录而不是临时注册注意演示前把测试账号密码写在纸上演示环境是否有网前端依赖 CDN 的框架需要提前处理数据库里的模拟数据是否足够真实包括科室、医生排班、历史问诊记录都要有而不是一张空表展示“暂无数据”。特别是排班数据一定要提前造好最近两天的数据很多同学的排班表只造了昨天的记录演示时选择了科室却发现没有号源可挂场面非常尴尬。造数的时候可以批量生成未来一周的排班和号源每个医生排班生成 5 到 10 个号源记录这不仅方便演示也方便你自己并发测试。关于做毕设的一点个人体会做完这个项目再回头看我最大的感受是毕设不是越难越好而是“能在规定时间做完还能讲清楚”才有意义。在线问诊系统这个题目最难得的地方是它业务完整又不过度复杂技术栈覆盖了 Java Web 开发的核心面。我自己的操作习惯是先把挂号到问诊到开处方这条核心链路用最简单的 CRUD 跑通再去加 Redis、JWT、并发控制这些加分项。这样就算时间不够你手里也有一个完整能跑的项目而不是一堆半成品模块。最后提醒一句所有的演示数据一定要自己模拟生成不要在系统里出现任何真实个人信息这既是做开发的底线也是对自己负责。