做毕设时我选了SpringBootVue这套“医院资源管理系统管理平台”说难不难说简单也真不简单——它几乎是资源类管理系统里最能练手的组合把人员、床位、设备、药品、号源这几类资源塞进一个完整业务模型里写一遍下来从CRUD到权限、事务、报表统计就都摸了一遍。这篇文章写给正在做毕设、课设或者只是单纯想用JavaMySQLSpringBootVue练全栈的同学。我会按我实际开发时的思路把项目拆解、数据库设计、后端核心逻辑、前端页面落地、部署和答辩避坑全部捋一遍。你可以直接拿这套框架改成门诊管理系统、体检预约系统甚至实验室设备借用系统换皮不换骨。1. 项目整体拆解医院资源管理系统到底在管什么1.1 需求模块与角色权限医院资源管理系统更准确说是一个面向中小型医院或院区的综合管理后台。核心目标不是看病而是把“资源”管起来让患者挂得上号、医生排得了班、床位查得到状态、设备不闲置、药品库存不断供。我第一版把系统拆成了六个业务模块基础档案科室、医生、患者、职工信息维护。排班与挂号医生排班表发布患者在线预约、取消预约。病房与床位床位分配、退床、按科室统计占用率。设备管理设备台账、借用归还、维修状态。药品与库存药品入出库、库存预警、效期管理。统计报表挂号和收入数据可视化给管理员看趋势。权限上采用经典的三层角色管理员拥有全部菜单医生能看到自己的排班、处理号源护士/前台负责挂号登记和床位操作。如果再细分还能加一个“患者”角色用于自助预约我当时就是靠这个角色把登录流程做成多角色跳转的答辩时很加分。这个项目适合毕设的关键点在于它不像电商系统那样卷订单并发也不像纯管理系统那样一眼到底。挂号、库存、床位天然带状态流转能讲出业务深度又不至于超出两三个月开发量。1.2 技术栈选型为什么是SpringBootVueMySQL技术栈用这套一方面是主流另一方面是真省事。后端选SpringBoot因为它把配置自动化做到了极致。我不需要像SSH项目那样写一堆XML一个spring-boot-starter-web就搞定Web环境用Maven管理依赖内置Tomcat打包成jar直接跑这对不爱折腾服务器配置的学生太友好了。版本建议用2.7.x别一上来追SpringBoot 3JDK要求、javax迁移到jakarta这些坑会让毕设进度直接卡一周。持久层我用的是MyBatis-Plus不是纯MyBatis。纯MyBatis写单表增删改查太琐碎MyBatis-Plus提供BaseMapper最简单的CRUD零SQL实现复杂查询再用Select注解或Wrapper条件构造器解决。这样既不想完全丢掉SQL思维又想提高效率是很务实的选择。前端选Vue配合Element UI。Vue的响应式数据绑定让页面状态管理非常直接Element UI则相当于给前端提供了一套现成的后台管理组件表格、表单、弹窗、日期选择器全是封装好的。我用的Vue 2 Element UI图的是资料多、组件稳、网上踩坑记录一搜一大把如果你想用Vue 3 Element Plus也可以核心思路一样只是部分API写法有变化。数据库选MySQL 8.0免费、轻量、学校机房都有。MySQL 5.7和8.0在连接驱动和时区配置上有区别建议新项目直接用8.0遇到“Public Key Retrieval is not allowed”就在JDBC连接串加allowPublicKeyRetrievaltrue。这套组合还有一个隐藏优势招人问起来不丢面儿Java后端 Vue前端 MySQL数据库是所有全栈岗位最标准的“打招呼方式”。2. 数据库设计与核心表结构2.1 核心表与关系数据库是整个项目的灵魂表结构设计合理后端能少写一半判断。我建议先设计表再写代码不要边写边加字段否则后面改接口会越改越乱。我的核心表设计如下sys_user用户表存放所有登录账号包含username、password、real_name、role_id、department_id、status。sys_role角色表常见就管理员、医生、护士、患者四种。department科室表记录科室名称、位置、电话、简介。doctor医生表扩展用户表关联科室包含职称、擅长领域、简介、排班状态。其实也可以直接用user表加role区分但单独拆出来更便于扩展排班和挂号。schedule排班表记录医生在某天某个时段出诊包含doctor_id、schedule_date、time_slot、total_slots、remain_slots、status。这个是挂号系统的核心资源表。patient患者表记录姓名、身份证、手机号、病历号等。appointment预约挂号表记录患者预约哪个排班包含appointment_no、patient_id、schedule_id、status待就诊/已就诊/已取消/已过期、create_time。bed床位表包含bed_no、department_id、status空闲/占用/维修、patient_id当前占用患者、enter_time。equipment设备表包含equipment_no、name、department_id、status正常/维修/报废、buy_date。drug药品表包含drug_code、name、specification、unit、price、stock、warning_stock、expire_date。drug_log药品出入库流水表记录操作类型、数量、操作人。表之间的关系很简单schedule关联doctor和departmentappointment关联schedule和patientbed关联department和patientdrug_log关联drug和sys_user。这个模型简化了真实医院系统的复杂度但把资源调度的核心逻辑完整保留了。CREATE TABLE schedule ( id bigint NOT NULL AUTO_INCREMENT, doctor_id bigint NOT NULL COMMENT 医生ID, schedule_date date NOT NULL COMMENT 出诊日期, time_slot tinyint NOT NULL COMMENT 时段1上午 2下午 3晚, total_slots int NOT NULL DEFAULT 20 COMMENT 总号源数, remain_slots int NOT NULL DEFAULT 20 COMMENT 剩余号源数, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 2停诊 3已结束, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_doctor_date (doctor_id, schedule_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT医生排班表;这里有一个几乎所有新手都会犯的错把排班的日期和时段存成字符串比如“2025-06-01上午”这样看似简单但后续统计“周一上午出诊医生数”、按日期范围筛选全都要靠LIKE去模糊匹配性能差还容易出bug。正确做法是日期用date类型时段用tinyint枚举查询用范围条件数据干净又高效。2.2 关键字段设计心得与注意事项设计字段时有四个细节特别值得注意。第一金额一律用decimal不能用float或double。药品价格、挂号费涉及精确计算浮点数会出现0.10.20.30000000000000004的经典问题记账对不上就是大事故。比如挂号费字段定义decimal(10,2)入库和查询都不用担心精度丢失。第二状态字段用tinyint不要用varchar。比如排班status1正常、2停诊、3已结束程序里用常量或者枚举类维护数据库查询和索引都更高效。如果直接存“正常”“停诊”中文乱码、删除、改名都是麻烦。第三所有表都要有逻辑删除标识deleted默认0删除改1。我见过同行直接用DELETE删用户表数据结果关联的外键报错、历史统计少数据最后还得从binlog里捞。做毕设虽然数据量不大但养成逻辑删除的习惯答辩时跟老师解释“防止误删、保留审计轨迹”这就是专业意识。第四时间类型统一用datetime。create_time默认CURRENT_TIMESTAMPupdate_time用ON UPDATE CURRENT_TIMESTAMP自动更新。有些教程习惯用varchar存时间字符串排序、范围查询全乱套不建议学。索引方面不需要建太多但要建在查询频率高的字段上。挂号查询的黄金条件就是“日期科室”所以在schedule表建(department_id, schedule_date)联合索引appointment表按patient_id查本人的预约记录建patient_id索引。细节做到这个程度面试被问到索引优化也有东西可讲。3. 后端核心实现从登录鉴权到资源调度3.1 登录鉴权与统一返回后端我分了四层controller、service、mapper、entity。controller只做参数接收和调用serviceservice写业务逻辑mapper操作数据库。刚开始写项目时容易把业务代码全堆在controller里最后Controller两百行Service空荡荡这是典型的坏味道。登录鉴权我没有用复杂的Shiro而是用JWT 拦截器自己手写一遍代码量不大但原理非常清楚。流程是这样的用户提交用户名密码service层校验MySQL中的账号状态。校验通过后生成JWT把userId、roleId、userName放进去设置过期时间两小时返回前端。前端把token存到localStorage每次请求在axios拦截器里放到header的Authorization字段。后端拦截器解析token如果过期或非法直接返回401前端再跳转登录页。// 生成token String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(roleId, user.getRoleId()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 120)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();这段代码里signWith的密钥一定要放在配置文件里不要写死到class。另外JWT是无状态的token一旦签发在过期前无法主动撤销所以“退出登录”只是前端删token后端拦截器不再认它但这在毕设场景里足够用。统一返回结果我也封装了一个Result类包含code、message、data三个字段。code为200表示成功401表示未认证500表示业务异常。所有controller都返回Result前端拿到code再判断。这样好处是所有接口的响应格式一致前端axios响应拦截器里可以统一处理错误码不用每个页面写重复的提示逻辑。3.2 排班、挂号这类核心业务的接口设计排班和挂号是最能体现业务能力的地方我重点说这两个。3.2.1 排班发布管理员/医生端选择科室、医生、日期、时段设定总号源数生成一条schedule记录。这里要防止重复排班同一医生同一天同一时段只能有一条有效记录。我在数据库加了唯一索引同时service里用count查询做二次校验。// 检查该时段是否已排班 long count scheduleMapper.selectCount(new LambdaQueryWrapperSchedule() .eq(Schedule::getDoctorId, doctorId) .eq(Schedule::getScheduleDate, date) .eq(Schedule::getTimeSlot, timeSlot) .eq(Schedule::getStatus, 1)); if (count 0) { throw new BizException(该医生在此时间段已有排班请勿重复添加); }3.2.2 预约挂号患者选了一个排班点“预约”后端要做的不是直接insert一条appointment而是要保证“号源不超卖”。这里我用的是MySQL乐观锁思路更新排班表剩余号源时带上remain_slots remain_slots - 1的条件判断。Transactional public Appointment bookAppointment(Long scheduleId, Long patientId) { Schedule schedule scheduleMapper.selectById(scheduleId); if (schedule null || schedule.getStatus() ! 1) { throw new BizException(该排班已停诊或不存在); } if (schedule.getRemainSlots() 0) { throw new BizException(号源已满请选择其他时段); } // 扣减号源 int rows scheduleMapper.updateRemainSlots(scheduleId); if (rows ! 1) { throw new BizException(号源被抢光请重新尝试); } // 生成预约记录 Appointment appointment new Appointment(); appointment.setAppointmentNo(generateAppointmentNo()); appointment.setPatientId(patientId); appointment.setScheduleId(scheduleId); appointment.setStatus(APPOINTMENT_STATUS_WAIT); appointmentMapper.insert(appointment); return appointment; }为什么要先扣号源再插入预约因为如果把insert放前面两个请求同时进来都发现remain_slots1都insert成功最后号源更新成0就出现了两条预约抢一个号的情况。先扣号源并且用update返回受影响行数来判断是否成功数据库行锁会保证同一时刻只有一个事务能扣成功这就是“原子性”。这个方法我加了Transactional注解号源扣减和预约单生成在同一个事务里任何一个失败就整体回滚。这是整个后端最值得在答辩时展开讲的一个方法因为它把事务、并发、资源一致性都包含了——我当时被问到“如果同一时刻100个人抢20个号怎么办”就靠这段代码解释清楚了。3.2.3 建立“排班看板”查询接口排班看板是前端首页的核心后端要提供按科室、日期、医生姓名多条件分页查询返回每个排班的预约进度。我用MyBatis-Plus的LambdaQueryWrapper连接条件配合Page分页代码量很小。public IPageScheduleVO getSchedulePage(ScheduleQuery query) { PageSchedule page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperSchedule wrapper new LambdaQueryWrapper(); wrapper.eq(query.getDepartmentId() ! null, Schedule::getDepartmentId, query.getDepartmentId()) .eq(query.getDoctorId() ! null, Schedule::getDoctorId, query.getDoctorId()) .ge(query.getStartDate() ! null, Schedule::getScheduleDate, query.getStartDate()) .le(query.getEndDate() ! null, Schedule::getScheduleDate, query.getEndDate()) .orderByAsc(Schedule::getScheduleDate, Schedule::getTimeSlot); IPageSchedule schedulePage scheduleMapper.selectPage(page, wrapper); // 再封装成VO补充医生姓名、科室名称 return convertToVO(schedulePage); }这里我用了LambdaQueryWrapper的条件构造query里的字段为null时自动跳过这个条件前端传什么就查什么不用写一堆if拼SQL。如果需要关联查询医生姓名可以用voList也可以在SQL里joinMyBatis-Plus有自定义分页的写法毕设里选择在service里二次查询姓名即可简单直观。3.3 权限控制与接口安全后端我只放行了登录接口和静态资源其余接口全部走拦截器校验token再根据角色判断是否有访问某个接口的权限。具体做法是定义一个RequireRole注解标注在controller方法上拦截器里解析token拿到roleId再和注解值对比。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { int value() default 1; }比如删除药品库存的接口只允许管理员调用我在方法上标RequireRole(ADMIN_ROLE_ID)拦截器发现不是管理员就返回“无权限”。这种自定义注解的方式比在service里自己写if判断看起来规范得多也体现了你对Spring AOP和注解机制的理解。接口安全还有一个细节update、delete接口不要直接用前端传来的id无限信任还要做一遍数据归属校验。比如护士只能修改自己所在科室的床位就要先查bed的department_id不是自己科室就拒绝。这部分写进接口里免得出现越权操作。4. 前端页面与交互落地4.1 Vue工程结构与路由权限前端我用Vue CLI创建工程目录结构很标准src ├── api // 接口请求封装 │ ├── modules │ │ ├── schedule.js │ │ ├── appointment.js │ │ └── drug.js │ └── request.js // axios实例封装 ├── assets ├── components ├── router │ └── index.js ├── store │ └── modules ├── views │ ├── login │ ├── dashboard │ ├── schedule │ ├── reservation │ ├── bed │ ├── drug │ └── statistics └── utils └── auth.js路由配置里我用了meta.roles做权限控制。每个路由meta包含允许访问的角色数组router.beforeEach里判断当前用户roleId是否在允许列表里不在就直接踢回首页或者提示无权限。{ path: /drug, component: () import(/views/drug/index), meta: { title: 药品库存管理, roles: [1] } }axios封装的核心是请求拦截器和响应拦截器。请求拦截器从localStorage取token放进header响应拦截器在code为401时清理本地缓存并跳转登录页在code为500时统一弹出错误提示。这样每个页面里的接口调用都不用重复处理错误了代码清爽很多。4.2 核心页面实现排班看板、预约挂号、数据统计4.2.1 排班看板排班看板页面是我花时间最多的地方。页面加载时调schedule分页接口用el-table展示日期、时段、科室、医生、总号源、剩余号源、状态。状态列用el-tag根据status字段切换颜色el-table-column label排班状态 width100 template slot-scopescope el-tag :typeformatStatusType(scope.row.status) {{ formatStatusText(scope.row.status) }} /el-tag /template /el-table-column筛选区用日期选择器科室下拉框。科室下拉框的数据是进入页面时从department接口拉的选完条件点查询重新调用接口。这个页面还加了一个“重置”按钮把所有筛选条件清掉并刷新列表这是后台管理页面里容易被忽略但对用户体验很重要的功能。4.2.2 预约挂号挂号页分成两步第一步选择一个排班第二步填写患者信息。排班列表旁边直接显示“剩余号源”少于5个时数字变红提示紧张。点击“立即预约”时前端确认弹窗后调用后端预约接口。成功之后刷新排班列表可以看到剩余号源减一。这里有个交互细节要防止用户短时间内反复点击“立即预约”导致重复提交。我在按钮上加了loading状态点击后立即禁用等接口返回成功或失败再恢复从源头拦住手滑和连点。后端的接口本身也是幂等性设计——同一排班同一患者重复预约在service层会先检查是否已有未取消的预约有就直接抛异常双层保险。4.2.3 数据统计统计页我只用了ECharts不引入重型BI组件。页面加载时调统计接口后端返回一个折线图数据近7天挂号量和一个饼图数据各科室挂号占比前端用setOption渲染图表。ECharts最常见的问题是容器宽度不对导致图表变形解决办法是在图表渲染前给它一个固定高度el-card里放一个带height: 400px的div并在mounted里初始化图表。如果tab切换后图表宽度计算错误可以在activated钩子里调用chart.resize()这个我在写多tab页面时踩过坑后来加了resize监听才彻底解决。4.3 前端常见细节心得前端还有一个容易忽略的点接口返回的时间。后端返回的LocalDateTime默认是ISO格式字符串如果格式不统一前端显示会很难看。我后端在配置里加了Jackson的全局时间格式统一成yyyy-MM-dd HH:mm:ss前端就不用每次手动格式化。Element UI的表格默认是英文的日期选择器、分页组件都有语言包。在main.js里引入zh-cn语言包就能解决否则老师演示时看到英文分页“Prev/Next”会很突兀。这个两行代码就能修复但很多人都会忽略。组件主题色我也顺手改了一下在scss里覆盖Element UI的$--color-primary变量换成医疗行业常见的蓝色整体界面显得更正式。这些小细节在答辩展示时都会让老师眼前一亮。5. 部署运行与答辩避坑指南5.1 从零跑起来的部署步骤毕设最怕的不是写代码而是演示前一天环境崩掉。我总结一套最稳妥的启动顺序照着做基本不会出大问题。安装并启动MySQL 8执行项目里的database.sql脚本初始化表结构和测试数据。用IDEA打开后端工程等待Maven下载依赖。改application.yml里的数据库账号密码、端口号、JWT密钥。运行Application.java启动后端。看到“Started Application in xxx seconds”说明启动成功。前端工程用VS Code打开执行npm install安装依赖如果下载慢就配置淘宝镜像源。执行npm run serve启动开发服务器浏览器访问localhost:8080能在登录页看到系统就说明前后端连通了。后端启动失败时优先看控制台报错。90%的启动失败来自MySQL连接问题host连不上、密码错误、数据库不存在、时区报错。时区报错就在连接串加serverTimezoneAsia/Shanghai。端口被占用就改server.port或者用netstat -ano | findstr :8080查出来杀掉进程别跟端口死磕。前端npm install失败比较常见的是node-sass版本和Node版本不兼容。我建议直接不用node-sass换成sass或者干脆用Element UI时不用scss自定义主题这样能省很大力气。如果一定要用就用项目对应版本的sass-loader别追新版本。5.2 常见问题与排查速查表我整理了一个速查表基本覆盖了开发和部署阶段遇到的高频问题。现象可能原因解决办法前端访问后端报跨域未配置CORS后端加WebMvcConfigurer重写addCorsMappings允许前端地址和所有请求头登录成功但用户信息拿不到前端请求没带token或token key错误检查axios请求拦截器确认header字段名和后端读取名一致预约挂号失败提示号源已满测试数据号源被耗尽在数据库手动把schedule表remain_slots调大或去排班页新增排班MySQL连接报Public Key Retrieval错误MySQL 8加密方式导致JDBC连接串加allowPublicKeyRetrievaltrueschedule查询不到数据前端传的日期是字符串“2025-06-01”接口匹配不上后端日期参数用DateTimeFormat(patternyyyy-MM-dd)npm run build内存溢出Node默认内存不足package.json里build脚本改成“build”: “vue-cli-service build --max_old_space_size4096”Element UI按需引入后组件样式缺失没引入对应组件样式或者按需插件配置错改为全量引入Element UI最简单毕设不差这点体积还有一个最隐蔽的坑前端本地调试时访问图片、上传文件是OK的一旦部署到服务器静态资源路径可能失效。这种情况通常是用了相对路径我建议所有接口前缀写成/api在axios的baseURL里配置后端统一用/api做context-pathNginx代理时再转发到Java服务路径问题全部集中在代理配置里解决。5.3 答辩和课设展示的加分技巧代码写完只是及格把项目讲出深度才能拿高分。我建议答辩前重点准备三个话题。第一为什么选择这个课题。不要只说“医院资源管理系统很常见”要说“它涵盖多角色权限、资源并发控制、状态机流转、数据可视化能与实际业务场景结合能系统考核工程能力”。这句话一出来老师就知道你不是随便选的题目。第二讲清核心难点。把3.2节的挂号扣减号源那段逻辑重点讲提“并发超卖、乐观锁、事务原子性”。这段代码是你项目里技术含量最高的部分也是最容易被问到的地方。第三展示扩展性思考。可以主动说“后续可以引入Redis做验证码和更高效的库存预扣用RabbitMQ做预约通知”“或者用Docker Compose一键部署前端、后端、数据库”。哪怕你只是了解没实际做也能展示你具备工程视野。演示时准备好“降级方案”。如果现场网络不稳定导致ECharts图表加载不出来就提前准备好几张截图放PPT里。如果数据库被人误改了数据就先把初始化脚本跑一遍恢复测试数据。演示页面不要只点静态页面要有意识地操作一次完整的业务流——管理员建排班、患者预约、护士分配床位、统计报表数字变化这条链路走通了整个演示就很完整、很有说服力。最后分享一个我最初踩坑之后的习惯做任何修改前先备份数据库。在项目根目录放一个reset.sh或者手动执行sql脚本任何时候测试数据乱了都能一键恢复。我遇到过答辩前五分钟数据库被同学乱删数据的情况要不是有备份脚本当场就得社死。这个习惯希望你从现在开始也养成。