前后端分离医院后台管理系统：SpringBoot+Vue+MyBatis+MySQL实践

前后端分离医院后台管理系统从架构拆解到部署上线的完整实践如果你正在找一份能真正跑通的医院后台管理系统源码或者想完整走一遍 SpringBoot Vue MyBatis MySQL 的前后端分离项目这篇文章应该能帮到你。我会把整个项目的架构设计、核心功能实现、数据库建模、部署过程以及那些不踩一次根本发现不了的坑全部摊开来讲。项目覆盖了预约挂号、门诊管理、药品管理、收费管理、住院管理等医院业务的核心模块既是练手的好素材也是理解企业级前后端分离开发流程的完整案例。我之所以想写这篇内容是因为这类毕业设计/个人项目在网上有大量版本但大多存在三个问题要么代码混乱没有分层要么数据库设计漏洞百出要么部署文档完全没法照着执行。我结合自己实际搭建和改造这类系统的经验把一套经过验证的完整方案整理出来。不管你是刚开始学前后端分离的学生还是想快速搭建内部管理系统的开发者这套方案都能让你少走很多弯路。1. 项目全景这套系统到底做了什么1.1 标题背后的核心诉求拆解很多人看到前后端分离医院后台管理系统这个标题下意识以为只是一个普通的 CRUD 项目。但仔细拆解一下你会发现它其实包含了几层不容忽视的信息**SpringBoot Vue MyBatis MySQL这套技术组合意味着什么、完整源码意味着什么、部署教程又意味着什么。先看技术组合。SpringBoot 负责后端接口与业务逻辑Vue 负责前端页面与交互MyBatis 负责数据库访问层MySQL 负责数据存储——这是目前国内中小型管理系统最主流、最成熟的搭配。它没有微服务、没有高并发中间件但恰恰是这种够用、稳定、易上手的选型才是大多数实际项目最需要的。医院后台管理系统本质上是一个业务复杂但并发可控的管理类系统它需要的是清晰的业务建模和稳固的架构而不是花哨的技术堆砌。再看完整源码。这四个字意味着项目不止是某个模块的 Demo而是要覆盖医院后台的核心业务闭环从用户登录、科室医生维护到患者挂号、收费结算再到药品出入库、住院管理。模块之间要有真实的数据关联比如患者挂了号就要能查到挂号记录挂号记录关联到收费单收费单关联到药品处方。这种业务链路的完整性才是一个管理系统项目真正的价值所在。最后是部署教程。这意味着这套系统不只是能在本地开发环境跑通还要能真正部署到 Linux 服务器上通过 Nginx 反向代理对外提供服务。很多项目源码能跑但不会部署一上服务器就各种 404、跨域、端口不通。所以我后面会专门用一整章讲部署过程把 Nginx 配置、Jar 包启动、前端构建这些环节全部过一遍。1.2 系统的用户角色与核心业务流程一个医院后台管理系统首先要理清楚谁在用和用来干什么。我在设计角色权限时参考了实际医院信息系统的通行做法抽象出四类核心角色角色核心职责典型操作系统管理员维护系统基础数据、管理账号权限科室维护、医生信息管理、用户管理、字典管理门诊医生处理日常门诊业务查看患者挂号、录入诊断、开处方、查看排班护士/收费员执行收费与日常业务操作患者登记、挂号收费、退费处理、费用查询药房管理员管理药品库存与发药药品入库、库存查询、发药登记、效期预警基于这四类角色系统的核心业务闭环可以概括为一条线患者建档 → 预约/挂号 → 医生接诊/开方 → 收费结算 → 药房发药。这条链路环环相扣每个环节都依赖上游产生的数据。如果患者没有先建档挂号就无从谈起如果挂号记录不存在收费模块就找不到对应的业务单如果处方没有开出来药房就不知道要发什么药。很多初级项目的问题就是把这些环节做成了孤岛每个模块单独能用但数据之间没有关联。比如患者管理是独立的增删改查挂号管理也是独立的增删改查两个模块互不引用这在真实业务里是完全不可用的。我在下面的架构和数据库设计部分会重点讲如何通过表结构和接口设计把这些业务串起来。1.3 面向的读者与适用场景这套方案适合谁来用我把它分成三类第一类是在校学生需要一个结构完整、能答辩、能演示的毕业设计或课程项目。这套系统覆盖了前后端分离开发的所有标准要素而且部署流程完整答辩时可以从架构设计、数据库建模、接口规范、安全性设计等多个维度展开内容量完全够。第二类是刚入行的初级开发者想通过一个完整项目理解企业级开发流程。这类项目的好处是麻雀虽小五脏俱全你可以在里面看到统一返回格式、全局异常处理、JWT 鉴权、分页查询、事务控制这些在实际工作中天天用的东西。第三类是医疗信息化领域的从业者想快速搭建一个内部原型或 Demo。这套系统的业务模型参考了真实医院信息系统的常见做法拿来改改就能用比自己从零开始设计要快得多。2. 为什么前后端分离是这类系统的必然选择2.1 医院后台管理的真实痛点如果让我用一个词概括传统医院后台管理系统的开发状态那就是耦合。页面代码、业务逻辑、数据库操作搅在一起改一个按钮往往要牵动一整条链路。更麻烦的是医院的信息科通常要对接多个外围系统任何一处小改动都可能带来连锁反应。前端想调样式后端想改接口两边在同一个工程里互相打架上线排期一拖再拖。前后端分离的核心思路就是把界面呈现和业务处理拆成两个独立工程。前端负责渲染、交互、调接口后端只暴露 RESTful API不管页面长什么样。两边通过 JSON 数据交互各自独立开发、独立部署、独立扩展。落到医院后台管理系统上这个模式的价值是实打实的并行开发前端页面和后端接口可以同时动工不用等对方。独立部署前端静态文件扔 Nginx后端打 Jar 包扔服务器互不干扰。按需扩容门诊高峰期挂号接口压力大可以只把后端服务横向扩几个实例前端不用动。多端复用同一套后端接口PC 后台、移动端、大屏都能复用。这些优势不是理论上的最佳实践而是我在多个实际项目中验证过的结论。特别是多端复用这一条医院场景里几乎是刚需——院长要看数据大屏护士站要用平板操作收费窗口要用 PC如果每个端都单独写一套后端那维护成本会直接失控。2.2 技术栈选型SpringBoot Vue MyBatis MySQL 为什么够用很多人一听到医院管理系统就觉得一定要上微服务、上 Redis、上消息队列。我的观点是先看规模再看技术。一个中等规模医院的单体后台系统日请求量通常在几十万以内数据量在千万级以下SpringBoot MySQL 这一套完全能扛住。盲目引入分布式组件只会把部署和运维复杂度拉高最终拖垮整个项目。选这套技术栈我当时的判断依据主要有这么几点维度选择理由后端框架SpringBoot约定大于配置内置 Tomcat一个 Jar 包就能跑社区资料极多前端框架Vue Element UI组件化开发效率高后台管理类页面的表格、表单、弹窗都有现成组件ORM 框架MyBatis复杂 SQL 可控性强医院业务的报表查询、多表关联写 XML 更直观数据库MySQL 5.7稳定、免费、运维生态成熟InnoDB 事务支持满足业务要求这里我想特别强调一下MyBatis 在医疗业务里的优势。医院系统里充满了各种不走寻常路的查询按时间范围统计门诊量、关联科室和医生表查排班、多条件动态筛选患者列表。这些需求如果用 JPA 那种全自动 ORM写起来反而别扭需要各种绕来绕去。而 MyBatis 的 XML 文件里写动态 SQL一套组合下来什么复杂查询都能直白地表达后期 DBA 审核 SQL 也方便。前提是你要守住一条底线核心业务表必须有索引SQL 必须走索引否则再好的 ORM 也救不了你。2.3 这套架构的扩展边界在哪里任何架构都有适用边界把这套单体前后端分离方案的边界画清楚你才知道什么时候该升级。它能覆盖的范围单院区或中等规模医院的后台管理包括预约挂号、门诊医生工作站、收费管理、药房药库、住院管理、基础数据维护、统计报表。并发几百到几千的在线用户量响应时间在可接受范围内。它不适合的范围跨院区的集团化医院、需要高并发秒杀的互联网医疗服务、涉及大数据量离线分析的科研场景。这些场景需要引入微服务拆分、缓存集群、消息队列甚至数据仓库属于另一个量级的架构设计。我见过不少团队在项目初期就堆了一堆中间件结果业务还没跑起来先把运维团队累趴了。架构升级的节奏应该是业务驱动的当单体应用真的出现性能瓶颈、团队协作冲突、某模块独立扩展需求强烈时再动手拆分也不迟。SpringBoot Vue 这套组合恰好给了你足够的缓冲期——只要业务模块划分清楚、接口设计规范后续拆微服务时很多代码是可以平移复用的。3. 从零搭建项目的完整流程3.1 开发环境准备清单先把环境准备好磨刀不误砍柴工。我列一份我实际用的版本组合照着装基本不会踩版本冲突的坑JDK 1.8 或 11推荐 1.8SpringBoot 2.x 最稳如果你用 SpringBoot 3.x需要 JDK 17Maven 3.6后端依赖管理和打包Node.js 14前端构建环境MySQL 5.7建议 8.0字符集选 utf8mb4IDEA 或 Eclipse后端 IDEVS Code 或 WebStorm前端 IDENavicat 或 MySQL Workbench数据库可视化工具这里有个小坑要提醒MySQL 8.0 的驱动和连接串跟 5.7 不一样如果你用 MySQL 8.0驱动类要写com.mysql.cj.jdbc.Driver连接串要加serverTimezoneAsia/Shanghai否则会报时区错误。很多新手在这个地方卡了半天其实就是一个参数的事。3.2 后端工程结构设计SpringBoot后端工程我用的是标准的 Maven 单模块结构包名按com.xxx.hospital这种风格组织。层与层之间严格单向依赖Controller 调 ServiceService 调 MapperMapper 操作数据库。hospital-server ├── pom.xml ├── src/main/java/com/xxx/hospital │ ├── HospitalApplication.java // 启动类 │ ├── config/ // 配置类跨域、拦截器、MyBatis配置 │ ├── controller/ // 接口层接收请求、返回JSON │ ├── service/ // 业务层核心逻辑处理 │ ├── mapper/ // 数据访问层接口 │ ├── entity/ // 实体类对应数据库表 │ ├── dto/ // 数据传输对象接口出入参封装 │ ├── vo/ // 视图对象给前端展示的数据封装 │ ├── common/ // 通用类统一返回结果、异常处理 │ └── utils/ // 工具类JWT、MD5、日期处理等 └── src/main/resources ├── application.yml // 配置文件 └── mapper/ // MyBatis XML 映射文件这种分层结构的好处是边界清晰Controller 只做参数接收和结果返回Service 只做业务逻辑Mapper 只做数据访问。谁越界了代码评审一眼就能看出来。我见过有些项目把业务逻辑写在 Controller 里几百行代码堆在一个方法里后期连自己都看不懂那就是给自己埋雷。3.3 前端工程结构设计Vue前端我用 Vue CLI 或 Vite 创建工程配上 Element UIVue 2或 Element PlusVue 3。如果你是完全的新手我更推荐先跟着较成熟的生态走资料多、坑少如果项目是全新的且你有一定经验可以直接上 Vue 3 Vite Element Plus构建更快。前端工程结构如下hospital-admin ├── package.json ├── vue.config.js // 开发代理配置 ├── src │ ├── main.js // 入口文件 │ ├── App.vue // 根组件 │ ├── router/index.js // 路由配置 │ ├── store/index.js // 状态管理 │ ├── api/ // 接口封装每个模块一个文件 │ ├── views/ // 页面组件 │ │ ├── Login.vue │ │ ├── Layout.vue // 整体布局侧边栏顶栏 │ │ ├── dashboard/ // 工作台 │ │ ├── patient/ // 患者管理 │ │ ├── doctor/ // 医生管理 │ │ ├── appointment/ // 挂号预约 │ │ ├── drug/ // 药品管理 │ │ ├── ward/ // 住院管理 │ │ └── statistics/ // 统计报表 │ ├── components/ // 公共组件 │ └── utils/ │ ├── request.js // axios 封装拦截器、Token处理 │ └── auth.js // 登录状态管理前端最核心的是request.js这个 axios 封装它负责统一处理请求头、Token、响应拦截和错误提示。我在里面做了三件事请求时自动带上Authorization头响应时统一判断 HTTP 状态码遇到 401 自动跳转登录页。这几行代码写好了前端所有页面的鉴权逻辑就都统一了不用每个页面重复写。3.4 数据库设计从业务出发的表结构医院后台管理系统的数据库设计我一般按业务域拆分成几个模块来规划这样表之间的关联关系清晰后续扩展也方便。核心表大致如下业务域表名核心字段说明系统管理sys_userid, username, password, real_name, role, dept_id登录用户角色区分管理员/医生/护士基础数据base_departmentid, dept_name, dept_code, parent_id科室树形结构基础数据base_doctorid, doctor_name, dept_id, title, schedule医生信息关联科室患者管理patient_infoid, patient_name, id_card, phone, birth_date, gender患者基本信息挂号预约appointmentid, patient_id, doctor_id, dept_id, visit_date, time_slot, status, fee核心业务表字段较多药品管理drug_infoid, drug_name, spec, unit, price, stock药品基础信息及库存收费管理charge_recordid, patient_id, appointment_id, total_fee, pay_status收费记录住院管理ward_info / inpatientid, ward_no, bed_no, patient_id, doctor_id病房与在院患者设计时有三条原则我坚持不放主键用自增 ID 或雪花 ID不用业务字段做主键。身份证、手机号都可能变不适合当主键。金额字段用 DECIMAL不用 FLOAT/DOUBLE。涉及钱的事不能有精度问题这是底线。业务表必须记录创建时间和更新时间两个字段加好后面查问题、做统计都离不开。特别要提醒的是appointment挂号表它是整个系统的流量入口牵涉到医生排班、号源扣减、收费记录、患者档案等多个环节。这张表设计好了系统就稳了一半设计不好后面各种脏数据会折磨你。号源扣减必须走事务先查询剩余号源判断是否充足再扣减同时创建挂号记录这几个步骤要放在一个事务里否则并发场景下会出现超卖。3.5 接口设计规范与统一返回格式前后端分离项目里接口设计规范比代码本身更重要。一个乱七八糟的接口风格会让前后端联调变成一场灾难。我统一采用 RESTful 风格配合一套固定的返回格式{ code: 200, message: 操作成功, data: { } }code业务状态码200 表示成功401 未登录403 无权限500 服务器异常message提示信息前端可以直接弹给用户看data实际业务数据可以是对象、数组或 null后端统一封装一个Result类所有 Controller 的方法都返回它。配合GlobalExceptionHandler全局异常处理器业务里抛出BusinessException(号源不足)前端就能拿到对应的错误返回。这样前端处理异常的逻辑就非常简单code 不为 200 就弹 message不用每种异常单独判断。接口的路径规划我举个例子方便你直接参考功能请求方式路径用户登录POST/api/auth/login获取当前用户信息GET/api/auth/info分页查询患者GET/api/patient/page?pageNum1pageSize10name张新增患者POST/api/patient修改患者PUT/api/patient/{id}删除患者DELETE/api/patient/{id}获取医生排班GET/api/doctor/{id}/schedule创建挂号POST/api/appointment取消挂号PUT/api/appointment/{id}/cancel收费结算POST/api/charge分页查询我统一用pageNumpageSize参数返回{ total: 100, list: [...] }这种结构前端配合 Element UI 的表格和分页组件基本上不用写什么额外逻辑。3.6 登录鉴权部分JWT 拦截器的落地实现登录鉴权是整个系统安全的第一道门我选择用 JWTJSON Web Token来实现无状态认证。这套方案的思路是用户登录成功后后端签发一个带有效期的 Token 给前端前端每次请求带上这个 Token后端通过拦截器校验 Token 的合法性和有效期。为什么不用 Session因为前后端分离后后端可能会水平扩展多个实例Session 存在单台服务器内存里负载均衡一转发就丢登录态。JWT 把用户信息加密在 Token 里后端不存状态天然适合分布式场景。当然JWT 也不是没有缺点——Token 没办法主动失效所以有效期不能设太长我一般设 2 小时配合前端在 Token 过期前自动刷新。具体落地三步第一步后端写 JWT 工具类负责生成和解析 Tokenpublic class JwtUtils { // 密钥要放到配置文件中不要写死在代码里 private static final String SECRET your-secret-key; private static final long EXPIRE_TIME 2 * 60 * 60 * 1000; // 2小时 public static String generateToken(Long userId, String username, String role) { Date now new Date(); Date expireDate new Date(now.getTime() EXPIRE_TIME); return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }第二步写拦截器校验请求头里的Authorizationpublic class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains(/auth/login)) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); try { Claims claims JwtUtils.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }第三步注册拦截器配置放行规则。静态资源和登录接口放行其他接口一律走拦截。这里有个很容易被忽视的安全细节前端不要把 Token 放在 localStorage 里做持久化因为 XSS 攻击可以拿到 localStorage 里的数据。稳妥的做法是放在内存中页面刷新后重新拉取或者用 httpOnly Cookie 存储。不过 httpOnly Cookie 涉及跨域携带问题需要配合withCredentials使用。对于学习项目Token 放内存 请求头携带已经够用但你要知道这个隐患在哪。3.7 前端核心页面开发逻辑前端页面我按布局 → 路由 → 页面组件 → 接口对接的顺序来推进。首先搭一个后台管理通用的 Layout左侧菜单、顶部用户信息、中间内容区。然后用 Vue Router 配置好路由最后逐个填充业务页面。所有列表页面都有固定的四板斧搜索条件区、表格展示区、分页组件、新增/编辑弹窗。以患者管理为例页面结构大概是template div classpatient-container el-form :inlinetrue :modelqueryParams el-form-item label姓名 el-input v-modelqueryParams.name placeholder请输入患者姓名 / /el-form-item el-form-item label科室 el-select v-modelqueryParams.deptId placeholder请选择科室 el-option v-ford in deptList :keyd.id :labeld.deptName :valued.id / /el-select /el-form-item el-form-item el-button typeprimary clickhandleQuery查询/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form el-table :datapatientList border stripe el-table-column proppatientName label患者姓名 width120 / el-table-column propgender label性别 width80 / el-table-column propphone label联系电话 width150 / el-table-column propdeptName label所属科室 / el-table-column label操作 width200 template #defaultscope el-button typeprimary sizesmall clickhandleEdit(scope.row)编辑/el-button el-button typedanger sizesmall clickhandleDelete(scope.row)删除/el-button /template /el-table-column /el-table el-pagination :current-pagequeryParams.pageNum :page-sizequeryParams.pageSize :totaltotal current-changehandlePageChange / /div /template流程很简单页面加载时调接口拿数据填充表格点查询时带上筛选条件重新请求点新增/编辑时打开弹窗提交时调保存接口。所有接口都封装在api/patient.js里不要在页面里直接写axios.get否则接口一变你要满项目地找改的地方。3.8 前后端联调与跨域处理前后端联调时最大的拦路虎就是跨域问题。前端开发服务器跑在http://localhost:8080后端跑在http://localhost:9090端口不同就产生了跨域。解决思路有两条我建议两条都掌握因为实际开发中两种场景都会遇到。方案一开发环境用 Vue 代理。在vue.config.js里配置 devServer 代理让前端开发服务器把/api开头的请求转发到后端。// vue.config.js module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:9090, changeOrigin: true } } } }这样配置之后前端代码里的请求路径写成/api/patient/page实际访问的是后端http://localhost:9090/api/patient/page。浏览器的角度是同源请求根本不触发跨域这是开发环境最优雅的解决方案。方案二后端开启跨域支持。这种方案用于无法使用代理的场景。SpringBoot 里配置一个 CorsFilter 即可Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意addAllowedOrigin(*)和setAllowCredentials(true)不能同时使用浏览器规范不允许。所以上面代码用了addAllowedOriginPattern(*)来绕开这个限制。跨域问题解决了剩下的联调就是调接口、看数据、对字段的重复工作。我的经验是联调前先把接口文档对齐每个字段的命名、类型、是否必填都确认好能省掉一半的返工时间。4. 项目部署从本地到服务器的全流程实录4.1 后端打包与部署后端打包很简单Maven 一条命令搞定mvn clean package -Dmaven.test.skiptrue打包完成后target目录下会生成一个可执行的 Jar 包。接下来把它部署到服务器上。服务器环境以 CentOS 7 为例先装 JDKyum install -y java-1.8.0-openjdk然后用nohup在后台启动服务nohup java -jar hospital-server-1.0.0.jar --spring.profiles.activeprod server.log 21 注意日志文件要单独输出这样排查问题的时候直接tail -f server.log就能看到实时日志。如果项目中有频繁修改配置的需求可以先把配置文件抽出来放在 jar 包同级目录用外部配置优先的方式避免每次改配置都要重新打包。4.2 前端构建与 Nginx 部署前端构建也是一条命令npm run build构建完成后dist目录下就是纯静态文件。把这些文件上传到服务器的某个目录比如/usr/share/nginx/html/hospital-admin然后配置 Nginx。我的 Nginx 配置思路是静态文件由 Nginx 直接返回/api开头的请求反向代理到后端服务。server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html/hospital-admin; index index.html; try_files $uri $uri/ /index.html; # 前端路由 History 模式必须加这行 } location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里有三个细节必须注意try_files $uri $uri/ /index.html这行不能省。前端路由默认用 History 模式刷新页面时如果直接请求某个子路径Nginx 找不到对应文件就会 404加上这行后所有路由都回退到index.html由前端路由接管。proxy_set_header要配全。后端要通过X-Real-IP获取真实客户端 IP做操作日志记录时用得上。不配的话拿到的全是内网地址。前端路由模式和生产环境要匹配。如果你用 History 模式上面配置就没问题如果你配置成 hash 模式那行加不加都行。我建议用 History 模式URL 更干净但前提是你得把 Nginx 回退配好。4.3 数据库初始化与配置调整服务器上的 MySQL 装好后把本地导出的 SQL 文件导入mysql -u root -p hospital_db.sql同时检查一下 MySQL 的字符集确保是utf8mb4否则存不了特殊字符遇到生僻姓氏也可能乱码。配置文件里数据库连接建议单独用prod的 profile把密码等敏感信息放服务器环境变量里不要提交到代码仓库——这是基本的配置安全习惯。部署完成后用两个简单命令验证服务是否正常# 检查后端端口是否监听 ss -tlnp | grep 9090 # 检查前端页面是否可访问 curl -I http://your-domain.com都通了系统就算正式上线了。5. 核心业务模块的实现逻辑与坑点5.1 预约挂号模块号源扣减与并发控制预约挂号是医院系统里最硬核的业务它同时涉及数据一致性和并发控制两个难点。先看基本流程患者选择科室 → 选择医生 → 选择日期和时段 → 确认挂号 → 扣减号源 → 生成挂号记录。这里最大的坑是并发扣减。想象一下某热门专家号只剩 1 个号源同一个瞬间有 5 个患者同时点挂号。如果没有并发控制5 个请求都可能读到剩余 1然后每个都成功扣减最后数据库里出现号源为负的荒谬数据。这不是理论问题是真实会发生的。我的解决方案是数据库行锁 事务Transactional public Appointment createAppointment(AppointmentCreateDTO dto) { // 第一步用悲观锁锁定号源记录避免并发扣减 DoctorSchedule schedule scheduleMapper.selectByIdForUpdate(dto.getScheduleId()); if (schedule.getRemaining() 0) { throw new BusinessException(该时段号源已约满); } // 第二步扣减号源创建挂号记录 scheduleMapper.decreaseRemaining(dto.getScheduleId()); Appointment appointment new Appointment(); // ... 设置字段 appointmentMapper.insert(appointment); return appointment; }核心是selectByIdForUpdate它会给这条排班记录加上行级排他锁其他事务必须等当前事务提交后才能操作同一行。配合Transactional保证扣减和插入要么都成功、要么都失败。这样并发再高号源也不会超卖。当然行锁也有代价——并发等待。如果系统并发量真的很大就得引入 Redis 预扣减 异步落库的方案那是更高阶的玩法。对于大多数医院后台系统数据库行锁已经足够不要过早优化。5.2 收费模块金额精度与支付状态机收费模块涉及的金额我全部用BigDecimal处理避免浮点数运算误差。这里有一个非常经典的坑// 错误示例0.1 0.2 0.30000000000000004 double total 0.1 0.2; // 正确示例使用 BigDecimal BigDecimal total new BigDecimal(0.1).add(new BigDecimal(0.2));涉及钱的项目任何浮点计算都是事故隐患。金额字段在数据库里用 DECIMAL(10, 2)在 Java 里用 BigDecimal在 JSON 里序列化成字符串。别小看最后一步——如果 JSON 返回的是数字类型前端 JS 处理时又可能引入精度问题返回字符串最保险。收费状态我用一个pay_status字段管理取值有待支付、已支付、已退款、已作废。状态流转要严格限制当前状态允许的操作目标状态待支付支付 / 作废已支付 / 已作废已支付退款已退款已退款无-已作废无-状态机的意义在于防止非法流转。比如已退款的单子不能再改回已支付否则财务对账就乱了。在代码里每个状态变更操作都要先校验当前状态是否允许不允许就直接抛异常。5.3 统计报表模块SQL 性能优化实战医院管理系统逃不开统计报表门诊量统计、科室收入统计、医生工作量排名、药品消耗排行。这些报表的 SQL 往往涉及多表联查 聚合函数 时间范围筛选是数据库性能的重灾区。我这里分享一个真实的优化案例。某次做门诊量统计SQL 大概是这样的SELECT d.dept_name, COUNT(a.id) AS visit_count FROM appointment a LEFT JOIN base_department d ON a.dept_id d.id WHERE a.visit_date BETWEEN 2024-01-01 AND 2024-12-31 GROUP BY d.dept_name数据量小的时候跑得飞快一旦appointment表到了几十万行这个查询开始变慢前端等 5 秒才出结果。原因是visit_date上没有索引每次都要全表扫描。优化办法很简单给筛选字段加索引。ALTER TABLE appointment ADD INDEX idx_visit_date (visit_date); ALTER TABLE appointment ADD INDEX idx_dept_id (dept_id);加完索引后同样的查询从 5 秒降到 0.2 秒。这个案例想说明的是接口变慢了八成是 SQL 没走索引别急着加缓存、上中间件。先用EXPLAIN看一下执行计划发现全表扫描或扫描行数很大优先加索引很多时候问题就解决了。5.4 科室树与字典管理通用性设计的价值医院系统的科室是树形结构比如内科下面有心血管内科呼吸内科。这种层级数据在后端的处理方式我建议做成通用的树结构工具先从数据库查出所有的科室数据在内存里组装成树形再返回给前端。public ListDeptTreeNode buildDeptTree(ListDepartment deptList) { MapLong, DeptTreeNode nodeMap new HashMap(); for (Department dept : deptList) { nodeMap.put(dept.getId(), new DeptTreeNode(dept)); } ListDeptTreeNode roots new ArrayList(); for (Department dept : deptList) { DeptTreeNode node nodeMap.get(dept.getId()); DeptTreeNode parent nodeMap.get(dept.getParentId()); if (parent ! null) { parent.getChildren().add(node); } else { roots.add(node); } } return roots; }树构建的核心逻辑就十几行但用得非常频繁科室下拉框、排班页面、报表筛选、权限配置都用得到。这种通用组件复用的思路比每个页面单独写一棵树要省事得多。还有一个容易被忽略的设计是数据字典。医院系统里有大量固定枚举患者性别、婚姻状况、费别自费/医保、药品类型、医院等级等等。把这些枚举值统一放到字典表里管理页面的下拉框选项都从接口获取而不是写死在代码里。好处是运维人员改字典不需要改代码、重新发布一个接口全搞定。这是很多初级项目欠缺的设计意识。6. 部署之后接口安全、性能优化与常见问题排查6.1 接口安全设计系统上线后安全问题就是头等大事。医院系统的数据涉及患者隐私对接口安全的重视程度要高于普通管理系统。我的安全清单大致如下密码存储绝不能明文。后端存储时做加盐哈希处理校验时比对哈希值不能存储可直接还原的密码。敏感接口做权限校验。不同角色管理员、医生、护士能访问的接口要分开控制SpringBoot 拦截器里加角色判断就行。比如只有管理员能访问系统管理类接口。接口参数要校验。不能信任前端传来的任何参数。插入操作要防 SQL 注入使用 MyBatis 的#{}参数占位符本身就能防注入但要注意动态表名、动态排序字段这类场景要用白名单校验。操作日志必须留痕。谁在什么时间做了什么操作都要记录。特别是财务类的操作出了纠纷要能追溯。敏感字段脱敏展示。患者身份证号、手机号等敏感信息列表页展示时脱敏处理只在详情和业务处理时展示完整信息。6.2 常见部署问题排查手册部署完成后大概率会遇到几个固定问题我把排查思路写下来你照着走就能解决问题一前端能打开但登录后请求全部 404先确认 Nginx 代理配置是否正确再确认后端接口路径是否和前端请求路径一致。最常见的原因是前端请求/api/login后端接口却是/login少了/api前缀。解决办法是后端统一加server.servlet.context-path/api或者在前端代理和 Nginx 里统一规则。问题二数据库连接报错 Communications link failure通常是 MySQL 没启动、端口不对或者密码错误。依次检查服务状态是否正常、端口是否监听、配置文件里的连接串是否正确。MySQL 8.0 还要确认驱动类写的是com.mysql.cj.jdbc.Driver。问题三中文乱码页面显示乱码先查数据库字符集确保表结构和连接串都是utf8mb4再查 Nginx 配置确保返回的响应头有charsetutf-8最后查前端 HTML 文件本身是否 UTF-8 编码。这三层任何一个错位都会乱码。问题四上线后接口慢优先用EXPLAIN分析高频 SQL加索引再看是否有多余的 N1 查询循环查数据库考虑用关联查询代替最后才考虑加 Redis 缓存。大部分慢接口是 SQL 问题不是架构问题。6.3 性能优化方向这套系统运行一段时间后你可能会关注性能优化。我按投入产出比排序给出我的建议数据库索引优化投入最低收益最大配合慢查询日志把执行时间超过 1 秒的 SQL 全部抓出来优化。Redis 缓存热点数据收益中等科室列表、医生排班、字典数据这类变化不频繁但读取频繁的数据放 Redis 能大幅降低数据库压力。前后端静态资源优化前端打包开启 gzip 压缩图片懒加载Nginx 开启缓存。异步化处理短信通知、邮件发送这类非核心操作用线程池或消息队列异步处理不让用户等待。记住一个原则优化要基于数据不要基于猜测。先用监控和日志找到真正的瓶颈再动手改。没有数据支撑的优化大多是白费力气。7. 写在最后的实操体会项目从头到尾走完我最大的体会是这类管理系统项目真正考验人的地方不在某个技术点有多深而在于把一堆看似简单的功能组织成一套健壮、可维护的系统。登录鉴权、增删改查、分页、部署上线每一个单独拎出来都不难但组合在一起就需要你在架构、规范、边界意识上有清晰的判断。几个具体的经验总结接口规范先定好再动手。前后端分离项目最大的成本是联调接口规范定好了联调就是填数据定不好就是互相扯皮。我强烈建议先把每个模块的接口清单用文档固定下来字段命名、类型、含义都写清楚再开始写代码。数据库设计要舍得花时间。我见过太多项目因为表结构设计不合理中期大改伤筋动骨。设计阶段多花 1 小时后期能省 10 小时。特别是挂号和收费这类核心表字段宁多勿少关联方向要想清楚。事务和锁的概念要真正吃透。并发控制不是加个锁就能解决的要理解事务隔离级别、行锁、乐观锁这些底层机制。医院系统里挂号、收费、库存扣减都是强一致性场景这块掌握不好系统早晚出事。部署文档要写好。项目做完只是开始能顺利部署起来、能快速排查线上问题才是真正的交付。我建议给项目写一份独立的部署文档包含环境要求、数据库初始化、后端启动步骤、前端构建步骤、Nginx 配置、常见问题处理这份文档的价值跟代码一样重要。最后分享一个小技巧。如果你后续想让这个项目更有竞争力优先补两个方向一是消息通知模块挂号成功短信提醒、排队叫号通知这是医院场景的高频需求二是移动端适配很多医生希望用手机查看排班和处理简单业务。这两个方向都能让项目从课堂作业进阶到实际可用。做这类系统没有所谓的一步到位只有持续迭代。希望这篇实践分享能帮你把这个项目真正跑起来、用起来并在过程中建立起属于自己的架构判断力。如果你在搭建过程中遇到具体问题欢迎带着报错信息来讨论我们下个项目再见。