医院后台管理系统实战：SpringBoot+Vue+MySQL前后端分离开发

医院后台管理系统这种项目，我前前后后接触过好几个版本，从最早的 JSP + Servlet，到后来的 SSM，再到现在的 SpringBoot + Vue + MySQL，技术栈换了好几轮。这次分享的这套医院后台管理系统源码，算是目前比较典型的组合形态：SpringBoot 负责后端接口，Vue 负责页面交互，MySQL 做底层数据存储，而且它是可以直接拉下来跑起来的完整项目，不是那种缺配置文件、少依赖的半成品。

这套系统解决什么问题，一句话就能说清楚：医院需要一个能把科室、医生、患者、挂号、病历、处方这些业务数据统一管起来的地方，传统的手工记录和 Excel 管理早就撑不住了。对开发者而言，它又是一个特别完整的练手项目——既能学到 SpringBoot 的后端分层写法，也能体验 Vue 的前后端分离开发模式，数据库表设计也跟着业务走，理解起来不费劲。无论你是刚学完 SpringBoot 和 Vue 想做课程设计的学生，还是在职想快速上手前后端分离项目的开发者，这套源码都有参考价值。

1. 项目概述与核心设计拆解

1.1 医院后台管理系统的核心需求

本质上，医院后台管理系统属于典型的 MIS（信息管理系统），核心目标是把医院日常运营中产生的数据从“散落各地”变为“统一管理”。站在业务角度看，它至少要覆盖两类人群的使用场景：一类是前台工作人员，比如挂号员，他们需要快速完成患者建档、挂号、退号操作；另一类是医生，他们需要查看患者信息、写病历、开处方。管理员侧还要管着科室维护、医生排班、用户权限、系统日志这类基础设施。

把这套系统拆开来看，功能边界其实非常清晰：基础数据管理、业务流程管理、系统管理、统计报表。基础数据管的是科室、医生、药品这些静态资源；业务流程管的是挂号到就诊再到缴费这条主链路；系统管理负责维护账号、角色和操作权限；统计报表则是从数据库里把数据聚合出来，给管理层做参考。需求理到这一步，数据库表怎么设计、接口怎么划分，心里基本就有谱了。

值得多说一句的是，这类项目最忌讳的就是一上来就写代码。我见过不少同学拿到类似需求，直接从建表开始，结果表建到一半发现功能对不上，回头又要改。正确顺序是先按上文说的四种业务域去拆分，画出功能清单，再设计数据模型，最后才动手写接口和页面。

1.2 前后端分离架构的层级设计

这套源码采用的是前后端分离结构，后端跑在 SpringBoot 内置的 Tomcat 上，默认端口一般是 8080，前端是 Vue 开发服务器，端口常是 8081 或者 8088。浏览器访问的是 Vue 页面，页面里发出的请求通过代理或直接跨域请求到 SpringBoot 接口，接口再操作 MySQL 把数据返回给前端渲染。

后端本身按经典的三层结构组织：Controller 层负责接收请求和参数校验，Service 层处理业务逻辑，Mapper 层（DAO）用 MyBatis 或 MyBatis-Plus 操作数据库。前端则按照 Vue 官方推荐的目录习惯组织，components 放公共组件，views 放页面级组件，router 管理路由，api 模块统一封装 axios 请求。

这套分层设计的最大好处是职责单一。Controller 里不应该出现冗长的业务代码，它只需要做参数接收和结果返回；真正的业务规则全部沉淀在 Service 层，这也方便后续加事务控制。我最开始写项目的时候容易犯一个毛病——把所有逻辑都堆在 Controller 里，三个月以后再回去看代码，自己都想不起来这段代码在干嘛。后来习惯了分层，代码可读性和可维护性提升非常明显。

1.3 数据库表之间的业务关联

MySQL 在这套系统里担任的是“数据底座”角色。医院的后台管理系统数据关联性很强，这不是 Redis 单纯缓存能替代的。比如挂号表要关联患者表和医生表，病历表要关联患者表和挂号记录，开出的处方又要关联药品表。这种强关系场景用外键加上规范的索引，查起来快，也好理解。

从建表思路上看，典型的设计如下：sys_user 存后台登录用户，sys_role 和 sys_menu 做权限控制；hos_department 存科室；hos_doctor 存医生基本信息，同时通过 department_id 指向科室；hos_patient 存患者档案；hos_registration 存挂号记录，里面同时存 patient_id、doctor_id、department_id 和就诊状态；hos_medical_record 存病历，核心字段包括主诉、诊断、医嘱，并且用 registration_id 跟挂号记录关联。一张挂号单对应一条病历记录，一次看病开出的多行药品，又落到 hos_prescription_detail 表里。

这里有个细节容易忽略：患者表里的手机号、身份证号属于敏感信息，虽然课程设计项目不强制加密，但如果真要在生产环境上线，建议至少对身份证号做加密存储或脱敏展示。后面我会再单独说合规的事。

2. 技术栈选型：为什么偏偏是这套组合

2.1 后端选 SpringBoot 的三个直接理由

现在做 Java 后端项目，SpringBoot 基本是默认选择。核心原因是它把 Spring 生态里大量繁琐的配置变成了“默认值”，原来要写一堆 XML 配置的事务、数据源、扫描包，现在引入对应的 Starter 依赖就行。拿这套系统来说，后端需要做 Web 接口、连 MySQL、执行 SQL、做权限校验这几件事，对应的依赖无非是 spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java，几个依赖一加，配置就完成了大半。

SpringBoot 内置 Tomcat 这一点，简化了部署。以前做 SSM 项目，要把 war 包丢到外部 Tomcat 的 webapps 下面，中间不知道要踩多少坑；现在 mvn package 打出一个可执行 jar，java -jar 直接运行，对个人开发者和学习者极度友好。所以这套源码标着“可直接运行”，本质上就是占了 SpringBoot 的便宜。

还有一点，SpringBoot 的自动装配机制对新人很友善。数据库连接、事务管理、参数校验这些常用功能都有对应的自动配置，遇到问题去查官方文档也好查。我刚转 SpringBoot 那阵子，光是把 DataSource 配置弄明白就省了不少事，它比 SSH/SSM 时代着实容易太多。

2.2 前端选 Vue 是因为组件化太适合后台

后台管理系统跟 C 端官网不一样，它的页面大部分是“表格 + 表单 + 弹窗”这三种模板来回组合。这种场景如果用原生 JS 写，每个页面都要重新写一轮 DOM 操作，重复劳动不说，改起来还容易牵一发动全身。Vue 的组件化机制恰好解决这个问题——把表格封装成一个组件，把表单封装成一个组件，甚至把“搜索栏 + 表格 + 分页”这一整套查询布局拉成一个组件，每个页面只需要传数据和方法进去就行。

Vue 的数据双向绑定也让表单填写体验好很多，用户输入什么，数据对象里立刻就变了；列表页的筛选条件同步给查询请求，刷新表格数据，写着很顺手。二点零版本是这个项目流行的时代，但现在写 Vue 也大差不差，只是组合式 API 和 setup 语法更简洁。如果你手里这套源码已经升级到 Vue3，那更好；如果还是 Vue2，也不用觉得过时，因为核心思想完全通用。

前端和后端分离之后，联调往往是个痛点。好在这套项目一般都会在 Vue 的 vue.config.js 里配置 devServer 代理，开发时所有 /api 开头的请求自动转发到后端的 8080 端口，这样页面永远不会遇到跨域问题。这个配置我在后面“快速启动”章节会单独展开。

2.3 MySQL 到底强在哪

MySQL 是这套系统里争议最小的组件。它能走到今天这么大用户量，靠的是三点：免费开源、资料多、稳定可靠。对于医院后台这种 OLTP（在线事务处理）类型的业务，MySQL 的关系模型和事务机制完全压得住。挂号、病历、处方这类操作往往伴随着多表写入，例如挂号成功还要更新当日号源剩余数，一个业务里至少两条 SQL，这时候必须依赖事务的原子性，要么全成功要么全回滚。MySQL 的 InnoDB 引擎在这方面的表现非常成熟。

数据库版本建议用 5.7 或 8.0。5.7 是老牌稳，网上资料几乎能解决所有问题；8.0 性能更好，默认字符集就是 utf8mb4，对中文存储更友好。唯一要注意的坑是 8.0 的加密插件改成了 caching_sha2_password，老版本的 Navicat 甚至一些项目的数据库连接字符串没配上 useSSL 会报 SSL 连接错误。这些问题都见过了，后面我会放到避坑章节仔细说。

3. 功能模块与数据库设计解析

3.1 核心功能模块逐项拆解

如果功能模块用一句话概括，这套系统的骨架是“入口管住，流程理顺，数据落地”。具体拆开是五个大模块。

登录认证与权限管理。后台系统最先要解决的是“谁能进来”的问题。用户输入用户名密码，后端校验通过以后生成一个 Token（常见方案是 JWT），前端把 Token 存到本地，之后每次请求都在请求头里带上，后端再用拦截器统一校验。权限模型一般是经典的 RBAC：用户关联角色，角色关联菜单和按钮权限。比如医生角色登录以后，菜单里只有“我的患者、病历管理、处方管理”，而管理员能看到“系统管理、数据统计”这些全部菜单。

基础数据管理。科室和医生是医院运行的基础。科室维护一般包含科室名称、主任、位置、简介；医生管理要维护姓名、职称、所属科室、擅长领域、出诊时间、号源总数。这些基础数据的质量直接影响后续挂号和排班，所以后台要对输入做校验，比如手机号格式、号源数字范围等，避免脏数据进入业务流程。

门诊挂号管理。这是整个系统里业务流程最核心的一条线。操作员选择科室、选择医生、选择就诊日期，系统会展示剩余号源；确认以后填写患者信息或从已有患者档案里直接选人，挂号成功就生成一条挂号记录，同时扣减号源。退号则做反向操作，把号源加回去，并更新记录状态。这里牵涉到并发问题，同一时间好几个人抢最后一个号，如果不做控制就会超号。常规做法是数据库更新时带上剩余号源数的条件判断，比如 update hos_doctor set remain=remain-1 where id=1 and remain>0。

病历与处方管理。医生进入接诊工作台，可以看到当天的挂号列表；点开一个患者就能写病历，记录主诉、现病史、既往史、诊断结论，并开出药品处方。处方明细会关联药品表和剂量用法字段。这部分业务还牵涉到“同一份病历不能被两个人同时编辑”的并发控制，课程设计版本可能不处理，但至少值得在代码里留个锁的接口。

统计报表。从挂号记录表里按日期聚合，可以统计出门诊量；从处方明细表聚合，可以算出药品消耗和收入。这部分通常会用 SQL 的 GROUP BY 配合日期函数实现，前端再用图表组件展示，一眼就能看到趋势。

3.2 关键表结构与字段设计参考

真要动手建表时，有几张表的字段设计例子很值得参考。用户在系统里扮演多重角色，用户名和密码存 sys_user，角色和菜单权限分别存 sys_role 和 sys_menu 以及关联表 sys_user_role、sys_role_menu。密码字段存的不应该是明文，而是 MD5 或 BCrypt 加密后的字符串，这一步无论项目大小都不要省。

出诊医生的排班可以用一张表承载，比如 hos_schedule 表存 doctor_id、work_date、am_remain、pm_remain，上午和下午的号源数分开计算。挂号的表则记录 patient_id、doctor_id、schedule_id、visit_date、visit_time、status，status 用枚举值标记挂号、已就诊、已退号。这样统计每天门诊量时直接 count 挂号表里 visit_date 当天的非退号记录就行。

药品表其实可以独立成一个模块来做，字段包括药品编码、名称、规格、单位、库存量、售价。如果这套系统还做了药房库存扣减，那处方表写好之后就要联动更新库存，这是很多课程设计版本没做完整的地方，倒是非常适合自己动手扩展。

3.3 权限模型的前后端配合

权限模型听起来高大上，实现起来其实思路清晰。后端在用户登录成功后查询该用户拥有的角色和菜单标识，生成一个权限集合放进 JWT 或响应体里；前端拿到以后控制路由和按钮显示。也就是说，前端“看不到”不代表安全，后端的接口同样要做鉴权，防止有人绕过页面直接调接口。这套系统能够在面试里加分的地方，恰恰是前后端权限校验是否都做扎实了，缺一侧都算不闭环。

具体到后端，最省力的方式是做一个拦截器或过滤器，把需要登录的接口统一检查 Token 合法性，再把需要特定权限的接口加上权限注解。前端则用 router.beforeEach 做路由守卫，没有登录信息就踢到登录页；页面上用自定义指令控制按钮的显示隐藏。我见过很多项目控制住了页面，没控制住接口，最后被用户拿着 Postman 直接调接口改数据，这就是权限体系做成半吊子的后果。

4. 环境准备与快速启动全流程

4.1 本地环境版本怎么选

项目要想跑起来，第一步是环境版本要对得上。JDK 推荐 1.8 或者不低于 1.8 的版本，早几年项目基本是在 JDK8 上写的；如果手里是 JDK17 及以上，需要留意 pom.xml 里编译版本和依赖兼容性。Maven 使用 3.6 以上版本，Node.js 建议 14 到 16 之间，别一上来就装最新的 Node 20，老项目用到 node-sass 时常会因版本过高导致编译失败，这个坑尤其常见。

MySQL 的安装是新手最容易卡住的一环。MySQL 5.7 一路下一步安装，到设置密码时记好自己设的密码；MySQL 8.0 安装时选择默认认证方式的话，有些旧驱动连接会报错，要么换成 update 驱动版本，要么在连接串上加 allowPublicKeyRetrieval=true。装完之后建议再装一个可视化工具，Navicat 挺好用，但也可以用免费开源的 MySQL Workbench，或者直接命令行操作也可以。

工欲善其事，后端开发建议用 IntelliJ IDEA，社区版就够用；前端用 VS Code 或者 IDEA 都行，Vue 官方推荐的 VSCode 插件 Volar 记得装好。如果你之前没玩过前后端分离项目，这些工具安装好以后整个环境准备环节就结束了，接下来才是真正的项目运行。

4.2 后端启动流程与关键配置

拿到源码以后，先在 IDEA 里打开后端目录，等待 Maven 把依赖下载完。这个过程可能比较久，国内网络环境建议给 Maven 配置阿里云镜像，三个小时下不完依赖的痛我体验过，后来改成镜像仓库以后基本三分钟搞定。

接下来是关键动作：修改数据库连接配置。在 src/main/resources/application.yml 里找到下面这一段，改成你自己的数据库信息：

spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

建库的方式有两种。如果源码里附带 hospital.sql 脚本文件，用 Navicat 或命令行执行 source hospital.sql 导入；如果没有，就手动创建数据库，并让后端在启动时自动建表。前者更省心，表和测试数据一次搞定。

配置改好以后，直接运行主类上的 main 方法。启动日志里看到 Tomcat started on port(s): 8080 就说明后端起来了。如果端口被占用，可以在 application.yml 里改 server.port，改成 8081 或别的空闲端口都行。后端这个环节，最容易踩的坑就是数据库连接失败，后面专门有一节讲。

4.3 前端启动流程与常见操作

打开前端目录，先执行 npm install 安装依赖。这一步同样建议把 npm 源换成国内镜像，速度提升明显：

npm config set registry https://registry.npmmirror.com

依赖装完以后，执行 npm run serve 或 npm run dev。控制台会输出一个本地访问地址，一般是 http://localhost:8081，浏览器打开这个地址就能看到登录页。首次登录使用的账号密码要看 README 里的说明，一般会有管理员账号，比如 admin/admin123 或 admin/123456。

前端启动以后，页面会向后端接口发请求。如果你发现页面有数据展示但登录不了，优先看 F12 控制台里的请求是否报 404 或 401。404 意味着后端接口路径跟前端请求对不上，401 则多是 Token 失效或没带上。遇到前端跨域报错，检查 vue.config.js 里 devServer.proxy 配置是否把 /api 代理到后端地址：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

4.4 一键运行的整体节奏

整个项目从下载到跑起来，顺畅的话半小时内能完成。我通常建议按这个顺序推进：先装 MySQL 并导入 SQL 脚本->再打开后端改数据源配置并启动->然后打开前端 npm install 并 npm run serve->最后浏览器登录系统，逐个点击菜单，按业务顺序从挂号走一遍到病历处方，确认链路通畅。凡是中间出了问题，先不要急着怀疑代码——环境配置和版本不匹配占了这类问题八成的比例，把每一个报错截图存下来按错误关键字去搜，基本都能快速定位。

5. 常见问题与避坑实录

5.1 数据库连接类报错

这个类别是我见到的最高频问题。报错 Can't connect to local MySQL server through socket '/tmp/mysql.sock' 通常不是代码问题，是 MySQL 服务根本没启动，或者本地只装了客户端没装服务端。Windows 上检查“服务”里有没有 MySQL 服务，Linux 上执行 systemctl status mysql 查看状态，Mac 上则看 Homebrew 装的服务是否已经启动。

另一个高频报错是 SSL 连接错误。MySQL 8.0 默认开了 SSL 相关校验，旧驱动连的时候会报 javax.net.ssl.SSLHandshakeException。解决办法是在连接串后面加上 useSSL=false 和 allowPublicKeyRetrieval=true，这也是我在上文配置里直接写进去的原因。还有 Unknown database 报错，说明数据库名跟连接串里配置的名字不一致，要么改配置，要么去建同名数据库。

如果你导入 SQL 时报错说文件路径或权限有问题，建议直接把 .sql 文件的绝对路径写到 source 命令后面执行。Windows 下还要注意文件编码，SQL 文件最好保存为 UTF-8，否则导入中文会变成乱码。

5.2 前端依赖与构建报错

前端卡壳通常集中在 npm install 和 npm run serve 这两步。npm install 报 node-sass 安装失败，问题基本是 Node 版本过高，先检查 node -v，如果大于 16，可以考虑把 Node 降到 14 或 16，或者把项目里的 node-sass 替换成 sass。还有种情况是依赖下载一半失败，执行 npm cache clean --force 之后重装，或者删掉 node_modules 和 package-lock.json 重新安装。

前端启动成功但页面空白，多半是路由问题或 JS 报错。按 F12 打开控制台，看红色的报错信息。如果报错集中在某个组件文件，先用注释法把可疑组件逐步定位；如果页面能打开但接口数据不对，那就是接口路径或跨域问题，看 Network 面板里的实际请求地址和响应状态码最直观。

需要额外吐槽的是，有些项目默认端口是 8080，前端也是 8080，浏览器访问的“前端页面”实际上打到了后端接口上，页面会直接显示 JSON 或者 404。解决方式就是给前端换个端口，比如改 vue.config.js 里 devServer 的 port 为 8081，或者改 back 端 server.port。

5.3 SpringBoot 启动与打包的坑

后端启动时如果报 ClassNotFound 或者依赖无法解析，首先检查 Maven 的依赖是否完整下载。可以执行 mvn clean package -DskipTests 在项目根目录重新打包，如果这里通过，就说明代码本身没问题。有些项目会把本地依赖装到系统仓库里，IDEA 打开时可能没识别到本地仓库路径，在 Settings 里检查 Maven 的本地仓库配置即可。

打包之后想部署到服务器，直接把 jar 文件扔到服务器，java -jar xxx.jar 就能运行。如果端口冲突，用 nohup 启动时加 --server.port=8081 参数。这里有一点要强调：生产环境部署时不能再用开发阶段的 H2 或者本地 MySQL，连接配置要改成服务器的数据库地址，而且密码不要写明文到配置文件里，可以改成环境变量占位，比如 password: ${DB_PASSWORD}，这个习惯越早养成越好。

5.4 账号与权限的坑

登录不了是这类系统最常见的问题之一。先检查密码是否正确，再检查数据库里用户状态字段是不是被禁用。如果密码对但进不去系统，再看用户角色有没有分配菜单权限，没有角色和菜单权限的用户登录成功也会被踢出来或者一片空白。很多同学改完数据库里某个用户的密码以后忘记同步加密方式，比如后端用的 BCrypt，你在数据库里直接 UPDATE 成明文密码，那永远登录不上，正确做法是拿后端注册接口或写个测试类生成加密密码再 UPDATE。

还有种情况是 Token 过期时间设置太短，登录没几分钟就提示重新登录。如果是个人学习使用，可以在 JWT 配置里把过期时间调长一点，放到一天或更长；如果你打算在面试里演示这个项目，建议保持一个短过期时间并在前端做好 401 自动跳回登录页的逻辑——这个体验细节很加分。

5.5 常见问题速查表

为了方便后面的人排查，我把上面这些问题整理成一个速查表，保存下来遇到问题先对号入座。

6. 安全合规与代码整洁的一些体会

借着这套医院后台管理系统，我想多说一点安全与合规的事。做任何包含患者个人信息的系统，尤其是医疗健康数据，一定要有隐私保护的意识。哪怕只是课程设计或者个人练习，代码里也不要把真实身份证号、手机号写死在页面上，更不要明文存储密码。能用加密就加密，能脱敏就脱敏，该做权限控制就要做权限控制。

牙疼医院信息管理系统，也在用户登录处加了 BCrypt 加密，数据库里没有一条明文密码。把接口、数据库、前端三个层面过了一遍，把硬编码的账号密码全部清理掉——这是一个好习惯，也是一个加分项。

关于代码整洁，我的体会是：这套系统运行成功只是第一步，代码结构才是拉开差距的地方。建议拿到源码以后先不要着急改功能，找一个模块从头到尾读一遍，把 Controller、Service、Mapper 三层之间的调用关系画出来。然后试着给某个模块加上一个字段，比如给科室表加一个“备注”字段，走一遍数据库、后端实体类、VO、前端表单和表格的完整链路，这个动作做完，你会对“全栈开发”四个字有完全不一样的理解。再往后做，可以试着把代码里写死的配置改成 application.yml 里的配置项，把登录逻辑中的 Token 换掉或加一层刷新机制——这些改造每一步都能让你真正掌握这套源码。

最后再分享一个我自己的习惯：无论项目大小，拿到手之后先跑通，再增加一个小功能，最后把部署上线走一遍。这个过程，就是一套信息管理系统的完整生命周期。希望这篇分享能让你少踩几个坑，早日把项目跑起来。