又到了一年一度挣扎毕业设计的季节。前阵子群里又有人问"什么题目好做"，我给出的答案一直很明确：找个业务边界清晰、需求味很足、技术栈主流的方向下手。中西诊所管理系统就是很典型的这种题目，它基于SpringBoot做后端，覆盖挂号、门诊、划价、收费、中西药房、库存、会员、统计报表这些闭环业务，需求一听就懂，代码量够，论文故事也讲得圆，评审老师几乎不会问出超出项目本身的问题。
这篇文章把我从选题、架构、表设计、核心编码到论文答辩的完整过程摊开讲一遍，既讲SpringBoot实现这类系统时的关键取舍，也说清楚哪些地方容易翻车。如果你正在纠结毕设、想拿现成源码做二次修改，或者单纯想找一份能练手的全栈项目，这篇都能给你实际可用的参考。
1. 中西诊所管理系统选题：为什么这个题目值得做
先说选题逻辑。很多同学选系统类毕设的时候有个通病：要么选"通用进销存"，要么选"校园二手交易"，业务逻辑跟网上已有项目高度重复，答辩时根本没得讲。而中西诊所管理系统的妙处在于它有一个很独特的业务线——中医和西医业务要同时在系统里跑。
西医部分挂的是普通门诊、检查检验、处方划价；中医部分则涉及辨证分型、中药方剂、煎药登记、理疗预约、针灸推拿项目计费。两类流程在挂号、收费、库存环节又必须统一。这种"同系统内两条业务线并行、又要在核心节点合并"的特点，恰恰是毕业设计论文里最有话可说的点，需求分析、功能模块、数据库设计、业务难点这些章节全都有真实的素材可以展开。
从工作量看，这个题目也很合适。后端涉及用户/权限、患者档案、医生排班、挂号、门诊接诊、电子处方、收费划价、中西药房库存、药品入库、供应商、报表统计，前端的页面量大约15-18个，再加小程序患者端和后台管理端的话，工作量足够撑起一篇毕业论文，又不至于失控做不完。
从就业角度说，SpringBoot技术栈依旧是绝大多数中小型企业内部系统的主力。答辩的时候你讲"用了SpringBoot+MyBatis Plus+JWT+RBAC权限模型"，面试官看了也会觉得你做的不是一个玩具项目。Java方向的岗位，微服务问得狠，但单体项目的分层设计、事务处理、权限控制反而是入职后立刻要用的东西。
2. 技术选型分析：SpringBoot搭配Vue和小程序的方案为什么稳
2.1 SpringBoot核心优势哪里最实用
SpringBoot解决了传统SSH或SSM集成配置繁琐、依赖版本难控的问题。我搭这个项目的时候，直接在Spring Initializr里生成骨架，选Spring Web、MyBatis Plus、MySQL Driver、Lombok、Validation，两分钟就把基础环境拉起。内嵌Tomcat这一点尤其爽，打包成jar后在北京010、MySQL、Redis这些必备中间件之外，不用在服务器上单独装容器就能跑，实训演示和答辩演示都省了很多环境问题。
选SpringBoot还有一个现实原因：出问题好排查。诊所管理系统这种业务密集型的单体应用，遇到最多的就是SQL不对、事务没生效、跨域没配好这类问题。SpringBoot配合Actuator可以看运行时状态，配合全局异常处理可以让错误信息统一返回前端，等比网上那些SSH项目老代码好调试太多。
2.2 前端方案：后台管理用Vue还是JSP
标题里同时列了Java、PHP、Python、C#、小程序这些方向，其实它们对应了不同的毕业设计实现路线。如果走纯Java路线，我建议前端尽量选Vue3+Element Plus，后台管理界面做出来美观度高，表格表单、弹窗、树形控件这些组件在中西诊所系统里几乎全部用得到。Element Plus的表格自带筛选、排序、分页，写药品库存列表和挂号记录列表时省掉大量原生JS的活。
小程序端可以单独选微信小程序。患者端的功能不需要太重，主要是注册登录、查看医生排班、在线预约挂号、查看处方历史、在线缴费，这几个页面在小程序里实现并不复杂。前端复试的时候，小程序端算是一个加分亮点，因为评委能看到你除了Web端还做了移动端适配。
2.3 为什么加上单片机不是必需的
标题里出现了"单片机"，但这个方向和中西诊所管理系统的主线其实是分开的。如果你的毕设题目挂了物联网、智慧医疗，可以在系统之外做一个硬件终端，比如用51单片机采集环境温湿度（DHT11）或者通过LCD1602显示候诊排队号，再通过串口或Wi-Fi模块把数据传给后端SpringBoot服务。这是一个扩展方向，不是核心。如果你纯粹选软件方向，不用为了"显得高级"硬加单片机模块，评审老师会追问硬件和业务之间的数据链路，说不清楚容易减分。
3. 需求分析与功能架构：把诊所的一整天装进系统
我把一条完整的就医动线梳理了一遍，这是做需求分析最有效的方式：患者到诊所 -> 建档或调取档案 -> 挂号（分中西医科）-> 医生接诊写病历开处方 -> 划价收费 -> 西药房取药/中药房抓药或煎药登记 -> 下次复诊。
这么一串走下来，系统需要支持的模块其实就明确了。下面是我最终确定的功能模块表：
- 系统管理：用户管理、角色权限、菜单管理、操作日志、数据字典
- 患者管理：档案建档、档案查询、历史就诊记录、过敏史/既往病史登记
- 医生排班：科室管理、排班计划、出诊状态、号源配置
- 挂号模块：窗口挂号、小程序预约挂号、退号、当天号源查询、挂号记录
- 门诊接诊：病历书写、诊断记录、辨证分型（中医）、西医诊断、医嘱
- 电子处方：中西药处方分开、模板处方、处方审核、处方历史查询
- 收费划价：门诊收费、中西药费合并计算、微信/支付宝/现金支付、退款
- 药房库存：西药库存、中药库存、采购入库、库存预警、效期管理、盘点
- 统计报表：日营收报表、科室工作量、药品消耗排行、患者流量分析
- 小程序端：患者注册、浏览排班、预约挂号、查看报告/处方
这个列表不是拍脑袋想的。每个模块都在对应业务流程上有明确输入和输出。划价收费模块的数据一会儿要流向收入统计，药房发药后库存要联动减扣，患者档案要覆盖全生命周期，这些功能间的依赖关系，在后边的数据库设计里全部要落成外键和关联表。
4. 数据库设计：从患者档案到中药库存的表结构拆解
4.1 核心表及字段梳理
诊所管理系统的数据量不大，但是表数量多，关系繁杂。我一共设计了20张核心表，这里挑几个关键的讲。
用户与权限相关三张表：sys_user、sys_role、sys_menu，再加一张user_role关联表。权限模型我用的是经典的RBAC，后端按角色注入菜单权限和操作权限，前端用路由守卫控制页面访问。这几张表是几乎所有管理系统的地基，字段上重点关注status（启用禁用）、del_flag（逻辑删除）。
患者档案表patient：id、patient_no、name、gender、birth_date、phone、id_card、address、allergy_history、medical_history、create_time、create_by。患者档案是一切的起点，所以patient_no建议用规则生成，比如"P+年月日+四位流水"，保证在分页查询和关联查询中好辨识。
医生排班表doctor_schedule：id、doctor_id、department_id、schedule_date、period_type（上午/下午/晚班）、total_num、used_num、status。total_num和used_num这两个字段一排出来，就是挂号模块的号源控制核心。
挂号表registration：id、patient_id、doctor_id、schedule_id、visit_type（西医/中医）、fee、status（待就诊/已完成/已退号）、register_time。这张表关联了患者、医生、排班，是中西两条业务线的第一个汇聚点。
处方表prescription：id、registration_id、patient_id、doctor_id、prescription_type（中药/西药）、diagnosis、syndrome（辨证分型）、notes、total_amount、status。中药处方和西药处方共用这张表，通过prescription_type区分。处方明细表prescription_item：id、prescription_id、drug_id、drug_name、specification、quantity、price、amount、usage_info。usage_info对中药特别重要，要记录"每日一剂，水煎服，早晚各一次"这类煎服法信息。
中药库存表的特殊性：中药库存表tcm_stock和西药库存表western_stock可以分开设计。西药按通用名/规格/批次管理，中药按药材名称、产地、单位（g/kg）、库存量管理。中药的计价单位和开方单位得单独处理，比如医生开具时按"克"写，库存单位可能是"kg"或"袋"，处方划价时需要换算。
4.2 字段类型的几个细节
设计表的时候有几个细节吃过亏。金额字段一律用decimal(10,2)，别为省事用double，不然累计统计会出现0.1+0.2不等于0.3的问题。时间字段统一用datetime，创建时间用create_time，更新时间用update_time，配合MyBatis Plus的自动填充功能。逻辑删除字段用tinyint，0正常1删除。
另外，id_card和phone这些字段长度留足。身份证号现在18位，加上将来的可能性，varchar(32)稳妥。text类型的字段比如病历内容、处方说明，不要放主表查询里，拆出来或者只在详情页加载，否则列表查询会变慢。
5. 核心业务实现：挂号、划价收费、中药库存这三个最难的点
5.1 挂号并发控制
挂号看起来简单，实际上最容易出并发问题。想象一个场景：某个热门医生的号源只剩最后一个，两个患者同时提交挂号请求，数据库如果没做控制，used_num可能加两次变成超过total_num，或者同一个号被两个患者抢到。
我用的是乐观锁方案。doctor_schedule表里加一个version整数字段，更新号源时执行如下逻辑：
int count = doctorScheduleMapper.updateUsedNumAndVersion(scheduleId, usedNum + 1, version); if (count == 0) { throw new BusinessException("号源已被抢完，请选择其他时段"); }对应的SQL片段：
UPDATE doctor_schedule SET used_num = used_num + 1, version = version + 1 WHERE id = #{scheduleId} AND used_num < total_num AND status = 1把判断和扣减放到一条SQL里，通过影响行数判断是否成功，这样既避免了超卖，也避免引入分布式锁这种牛刀杀鸡的方案。挂号成功后同步往registration表插入记录，整个过程用@Transactional包住，保证事务一致性。
5.2 划价收费的金额计算
划价收费模块要处理的最大陷阱是：一张处方里既有西药又在中西药房取药，收费时要一次性划价，但费用明细要能区分中西药。所以在prescription表中total_amount存的是整单合计，收费记录顶层按整单收，不拆多条；药房发药时按明细项目核销。前端展示处方明细时，通过prescription_type和item明细分tab展示中、西药区块。
收费记录表payment需要留支付方式和支付流水号字段。实际开发中用支付宝或微信官方接口需要商户号、证书等资质，学生毕设阶段通常不具备。我用了一个更务实的方案：模拟支付。后端生成订单后，前端调用一个mock支付接口，sleep几秒后回调成功，同时生成payment记录。论文里可以写清楚"本系统实现了支付流程闭环，实际生产环境可无缝对接微信支付V3接口"，评委完全能理解，也避免了资质问题卡住项目。
5.3 中药库存扣减与发药联动
中西诊所和普通药店最大的区别就是中药库存的特殊性。医生开方时按克、按剂量开，药房抓药时要换算总量并扣减库存。下面是我在处方审核通过后进行库存扣减的完整逻辑：
- 遍历处方明细，按药材ID汇总总用量
- 将总用量换算为库存单位，比如开方总量为150g，库存单位是kg，则换算为0.15kg
- 执行库存扣减SQL，携带库存校验条件
// 按药品id汇总处方用量 Map<Long, BigDecimal> totalUsageMap = itemList.stream() .collect(Collectors.groupingBy( PrescriptionItem::getDrugId, Collectors.reducing(BigDecimal.ZERO, PrescriptionItem::getQuantity, BigDecimal::add) )); for (Map.Entry<Long, BigDecimal> entry : totalUsageMap.entrySet()) { int rows = tcmStockMapper.reduceStock(entry.getKey(), entry.getValue()); if (rows == 0) { throw new BusinessException("药品库存不足，请先采购入库"); } }在真实抓药场景中，药师抓完还要确认发药，库存扣减放在"发药确认"动作里，而不是处方开立时。这样设计更符合业务习惯，医生开方只是预占，药房实发才扣库存。理疗、针灸这类服务项目不涉及库存，只走服务收费，所以在收费明细里增加了item_type字段区分药品和服务。
6. 开发中容易翻车的七个坑和排查链路
这些坑都是我实际开发中踩过的，如果你也做同类系统，照着这个思路能省很多时间。
6.1 MyBatis Plus分页插件失效
症状：Page对象传进去，查出来还是全量数据。原因：没有配置MyBatis Plus的分页拦截器。解决：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }另外，分页查询多表关联的时候，Page要作为第一个参数传给自定义Mapper方法，别放在中间。
6.2 LocalDateTime前后端序列化不一致
实体类用了LocalDateTime，前端拿到的时间格式是一串数组或者带了字母T的ISO格式。解决办法：在application.yml里全局统一格式，也可以在字段上配合@JsonFormat注解。
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8要注意的是，如果用了@JsonFormat，优先级会覆盖全局配置，字段和全局配置最好保持一致。
6.3 事务不生效的根本原因
Spring的事务是AOP代理，同类内部方法之间调用时事务会失效。我犯过的错是：在Service层一个方法里直接调用本类的另一个@Transactional方法，第二个方法即使抛了异常，外层也没上报。解决方式是把需要事务的入口方法加注解，或者拆到不同Service互相调用。@Transactional默认只回滚RuntimeException，检查性异常不会自动回滚，必要的时候用rollbackFor = Exception.class。
6.4 挂号扣库存时版本字段没生效
如果忘记在实体类上给version字段加@Version注解，乐观锁等于没配。还有，更新操作的实体对象要带上当次查询的version值，不要只在SQL里写了version条件，但传入的是null。
6.5 跨域问题导致小程序调接口失败
前端页面在8080端口，后端在8081端口，存在跨域。一次开发的时候忘记了全局跨域配置，导致Vue联调时所有的POST请求全部报错。配置一个WebMvcConfigurer全局处理：
@Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); }注意allowedOriginPatterns比allowedOrigins("*")更宽松，允许带凭证的跨域请求。
6.6 逻辑删除和唯一索引的冲突
患者表的phone字段做了唯一索引，如果逻辑删除了一位患者，再新增同号患者会报唯一键冲突。这种情况可以加一个deleted_version字段，或者唯一索引改成(phone, del_flag)。简单点处理是把del_flag从0/1改成记录删除时间的bigint，0代表未删除，删除时写入时间戳，这样唯一键天然不冲突。
6.7 原生SQL里传List参数没写@Param
Mapper接口方法中传List时，如果SQL的foreach需要变量名，必须在参数上加@Param("list")，否则MyBatis会报参数找不到或者只能取第0个元素。这个问题几乎每个做分页筛选、批量删除的同学都会遇到一次，花五分钟记住就行。
7. 论文写作与演示答辩：把项目讲成高分毕设
系统做完只是第一步，毕业设计的分数很大比重在论文和答辩上。论文的结构我用了"选题背景-需求分析-概要设计-详细设计-系统实现-测试"这个标准六章法，但在内容上做了两个强化。
第一个强化是需求分析章节画了一个完整的业务时序图，把患者从注册到取药离开的全流程标清楚。时序图画清楚之后，后面的表结构设计、功能模块划分都是顺着时序往下拆的，导师看到了会认为你有全局观。
第二个强化是测试章节不只列了下拉框点选、必填项校验，还专门设计了一个并发挂号测试：用JMeter模拟50个用户同时抢一个号源，验证乐观锁生效。论文里有这个性能/并发测试，和那些只测增删改查的同学之间差距一下就拉开了。
答辩环节我准备的几个高频问题是：
- 为什么选SpringBoot不用SSH？答：简化配置、内嵌容器、生态系统成熟、就业需求大。
- 中西药两条业务线怎么在一个系统里共存？答：通过type字段区分，核心流程（挂号、收费、处方）共用，专业流程（辨证分型、亚单位换算、煎药登记）扩展。
- 库存不足你是怎么处理的？答：前端预检查、后端扣减SQL条件校验、事务回滚三重保障。
- 如果并发量再大怎么办？答：先做读写分离，再上Redis缓存号源，最后才是集群部署。按这个顺序答，基本挑不出错。
演示环节有个实操要点：提前把演示数据准备好。常用药品、医生排班、患者档案，每类数据准备8到10条，演示的时候不要现场录数据，直接展示列表、详情、统计报表，节奏快且不翻车。
这个项目整体做下来，我对SpringBoot单体应用的理解提升了不少，特别是事务边界、并发控制和数据库字段设计这些平时写练习Demo根本碰不到的东西。如果你也是拿现成源码起步，建议不要直接跑起来就交差，按这篇文章的思路把核心几个业务模块抠一遍改一遍，答辩的时候才讲得出东西。有具体不懂的模块，欢迎在评论区留言，我看到会回复。
