我带着这套医院后台管理系统跑完过两三个实际项目前后端分离从零搭到上线中间踩了不少坑也总结出一些值得写下来的东西。这篇就把整个系统的模块设计、技术选型逻辑、SpringBootVue前后端交互的落地细节、MyBatisMySQL数据层怎么组织以及从本地联调到服务器部署的完整过程原原本本过一遍。这套系统的代码结构和部署方式很典型尤其适合刚接触SpringBootVue的开发者和正在准备毕设或实训项目的学生参考——它不算炫技但把后台管理系统最常见的需求都覆盖了做完一遍对工程化开发的理解会比只看教程扎实很多。医院后台管理系统这类项目核心不是新潮技术而是业务边界是否清晰、数据模型是否合理、权限是否管得住。我把整个系统拆开来讲先看你需要做什么再看每层怎么实现。1. 医院后台管理系统业务模块与技术选型1.1 需求边界医院后台到底管什么先想明白一件事医院后台管理系统不是一个医院官网也不是给患者挂号用的前端应用它服务的对象是医院内部的工作人员。常见的角色包括系统管理员、门诊医生、收费员、药房药师、护士等。不同角色的操作对象完全不同这就需要系统具备清晰的模块划分。我在这套系统里规划了以下几大模块系统管理用户管理、角色管理、菜单管理、操作日志科室管理科室信息维护、科室排班基础数据医生管理医生信息、职称、所属科室、出诊状态患者管理患者基本信息、就诊记录、历史病历索引挂号管理挂号登记、号源状态、退号处理门诊收费收费单生成、费用结算、退费操作药房管理药品信息、库存变动、处方发药记录统计报表挂号量统计、收费汇总、科室工作量统计模块之间不是孤立的。患者先建档再挂号医生接诊后开处方收费员根据处方收费药房凭收费状态发药。这条链路就是整张业务关系表的主干。想清楚了这条链路数据库表设计的骨架也就出来了。1.2 前端模块与后端模块的映射关系前后端分离项目里一个常见误区是把前端页面和后端模块做一一对应的小接口系统结果Controller层写了一堆零散方法服务层几乎没有业务逻辑。我在这套系统里做了几个聚合处理前端把挂号登记页需要的患者搜索、号源查询、挂号提交三个操作合并成一个页面模块对应后端三个独立接口但通过同一个Vue组件内的API函数统一管理。收费模块的结算操作在后端一个事务里完成同时更新收费单状态和药品库存核减前端只需要收到成功或失败的结果。统计报表在前端用独立的图表组件展示后端提供聚合查询接口不在前端做二次统计。前端和后端分离的是代码与部署不是业务逻辑。业务规则必须留在后端前端只负责展示和交互。1.3 为什么选了SpringBootVueMyBatisMySQL这套组合这套组合在技术层面不是最新的但胜在稳。SpringBoot把配置简化到了几乎不需要你操心XML的程度内嵌Tomcat让打jar包就能跑Vue的组件化开发在管理后台这种大量表单和表格的场景里配合Element UI非常顺手MyBatis相比JPA更接近SQL本身医院系统里有很多多表关联统计查询写SQL的效率反而更高MySQL则是中小型项目最稳妥的选择运维资料多遇到问题基本都能找到答案。选型时也考虑过替换方案比如用Spring Data JPA真的会更省事吗实测下来JPA在简单CRUD上确实快但一旦涉及按科室统计某月的挂号量并按医生分组这类查询要么写Query注解SQL要么折腾 Specification。MyBatis直接上XML映射复杂SQL可控性高很多。Vue这边也没必要讨论管理后台生态里Element UI组件的成熟度摆在那里。2. 前后端分离落地从项目结构到接口规范2.1 后端项目结构与启动入口SpringBoot项目结构如果一开始就乱了后面所有联调都会难受。我习惯按照Controller-Service-Mapper-Entity四层加一个通用模块来组织hospital-admin ├── src/main/java/com/hospital/admin │ ├── common // 通用返回结果、全局异常、常量 │ ├── config // 跨域、拦截器、WebMvc配置 │ ├── controller // 接口层 │ ├── service // 业务层接口实现 │ ├── mapper // MyBatis Mapper接口 │ ├── entity // 数据库实体类 │ └── HospitalAdminApplication.java └── src/main/resources ├── mapper // MyBatis XML映射文件 └── application.yml启动入口就是一个标准的SpringBootApplication类。需要注意的细节是MapperScan注解扫描包路径以及application.yml里的多环境配置。我在本地开发、测试、生产三套环境之间切换通过spring.profiles.active来区分。很多新手直接把数据库密码写死在配置文件里我建议至少把生产环境的配置外置用启动参数--spring.profiles.activeprod加载application-prod.yml。2.2 前端项目结构与路由组织前端我用的是Vue CLI搭的项目目录结构按模块划分而不是按页面文件堆砌hospital-admin-web ├── src │ ├── api // 所有接口请求封装 │ │ ├── patient.js │ │ ├── registration.js │ │ └── statistics.js │ ├── router // 路由配置 │ ├── store // Vuex状态管理 │ ├── views // 页面组件 │ │ ├── system │ │ ├── registration │ │ └── pharmacy │ ├── components // 通用组件 │ └── utils // axios封装、权限指令等路由我采用了动态路由的思路登录时后端返回当前用户的菜单权限码前端根据权限码动态注册路由。这个设计在管理后台里非常重要否则前端把所有路由都写死用户通过URL直接就能访问没有权限的页面接口防了但页面没防体验很割裂。接口请求统一封装在src/api目录每个模块一个文件而不是在views里到处写axios。这样做的好处是接口URL集中管理后端改了接口路径只改一个文件。2.3 统一返回结构与异常处理前后端联调最容易吵架的就是接口返回格式不一致。我在后端定义了统一返回体public class ResultT { private Integer code; // 200成功其他为失败 private String message; // 提示信息 private T data; // 业务数据 }所有Controller方法统一返回Result对象成功时用Result.success(data)失败时用Result.error(code, message)。配合全局异常处理器RestControllerAdvice业务代码里不需要到处写try-catch。业务异常直接抛自定义的BusinessException全局处理器捕获后转换为统一的错误返回格式。前端axios封装的响应拦截器里做统一处理service.interceptors.response.use( (response) { const res response.data if (res.code ! 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, (error) { Message.error(error.message) return Promise.reject(error) } )成功状态下直接返回res.data页面里拿到的就是业务数据不需要每个页面都解包一次。这个约定从一开始就定清楚后面几十个页面全都复用同一套逻辑效率高很多。2.4 跨域问题前后端分离必须迈过的坎本地联调时前端跑在8080端口后端跑在9090端口浏览器一定会拦截跨域请求。处理方式有两种我在不同阶段各用了一种开发阶段前端Vue配置代理在vue.config.js里设置devServer.proxy把/api开头的请求转发到后端的9090端口这样浏览器看着是同源的最省事。部署阶段后端配置CORS在SpringBoot里加一个WebMvcConfigurer注入跨域映射允许指定来源访问。后端CORS配置示例Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }要特别注意allowCredentials(true)和allowedOriginPatterns(*)的搭配早期版本直接配allowedOrigins(*)加上Credentials会报错。这个坑我踩过后面部署章节还会提到。3. MyBatisMySQL数据层设计核心表与动态SQL实战3.1 核心表设计与关系说明数据库schema我用了十张核心表这里挑最关键的几张说明。用户与权限相关表sys_user用户表字段包括id、username、password、real_name、dept_id、statussys_role角色表如管理员、门诊医生、收费员、药师sys_menu菜单/权限表页面按钮级别到菜单级别sys_user_role和sys_role_menu中间表维护多对多关系业务核心表department科室表字段包括dept_name、dept_desc、statusdoctor医生表字段包括user_id、dept_id、professional_title、registration_feepatient患者表字段包括patient_no、name、gender、age、phone、id_cardregistration挂号记录表字段包括registration_no、patient_id、doctor_id、dept_id、visit_date、visit_time、fee、statusprescription处方表关联挂号记录、医生、患者prescription_item处方明细关联药品、数量、金额drug药品表字段包括drug_code、drug_name、specification、unit、stock、price表与表之间的关系非常明确user是登录账号doctor是user在业务上的扩展patient是独立实体registration是连接患者与医生的枢纽prescription_item把药品与处方关联起来。3.2 建表时的几个关键约束MySQL建表时我重点关注三件事。第一是编码建库时指定utf8mb4。医院系统里可能录入患者姓名万一遇到生僻字utf8会存不进去utf8mb4才能覆盖全部Unicode字符。建库语句长这样CREATE DATABASE hospital_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;第二是时间字段统一用datetime类型业务含义明确。挂号记录里的visit_date用date类型更合适它不需要时分秒。统计某天挂号量直接按visit_date分组即可。第三是金额字段别用float或double会出现精度问题。用decimal(10,2)药店收费和挂号费这种场景对金额精度有要求浮点数在累加计算时会有不可控的误差。3.3 MyBatis动态SQL复杂的条件查询场景医院后台最典型的业务就是列表查询而且几乎都是多条件组合查询。以挂号记录查询为例收费员要按日期查、按患者查、按医生查三个条件可能是任意的。MyBatis的动态SQL在这里就很好用select idselectRegistrationList resultTypecom.hospital.admin.entity.Registration SELECT r.*, d.dept_name, doc.doc_name FROM registration r LEFT JOIN department d ON r.dept_id d.id LEFT JOIN doctor doc ON r.doctor_id doc.id where if testpatientId ! null AND r.patient_id #{patientId} /if if testdoctorId ! null AND r.doctor_id #{doctorId} /if if testvisitDate ! null AND r.visit_date #{visitDate} /if if teststatus ! null AND r.status #{status} /if /where ORDER BY r.create_time DESC /selectwhere标签的妙处是能自动去掉第一个条件前面的AND不用自己在每个if里加where 11这种丑写法。动态SQL写多了会发现它的核心价值就是让SQL逻辑和Java判断解耦页面上的筛选条件加到后端Mapper里就能生效。3.4 分页查询与多表关联统计列表页几乎都要分页我在项目里用了PageHelper插件。接入很轻量引入依赖后在application.yml里配一个helper-dialect: mysql即可。接口代码里要分页时PageHelper.startPage(currentPage, pageSize); ListRegistrationVO list registrationMapper.selectRegistrationList(query); PageInfoRegistrationVO pageInfo new PageInfo(list);返回给前端的就是页码、每页大小、总记录数、总页数、数据列表五个字段。这里有个小坑PageHelper.startPage必须紧接着Mapper方法调用中间不能穿插任何其他SQL操作否则分页会错乱。这个插件底层是基于ThreadLocal的多线程环境下尤其要小心。统计报表是另一个常用场景。比如统计每个科室每月的挂号量直接用SQL的GROUP BY效率最高select idcountByDeptAndMonth resultTypejava.util.Map SELECT d.dept_name AS deptName, DATE_FORMAT(r.visit_date, %Y-%m) AS month, COUNT(*) AS totalCount FROM registration r LEFT JOIN department d ON r.dept_id d.id WHERE r.visit_date BETWEEN #{startDate} AND #{endDate} GROUP BY d.dept_name, DATE_FORMAT(r.visit_date, %Y-%m) ORDER BY month DESC /select这类返回Map的查询字段别名一定要和前端约定的key一致不然前端拿到数据又要做一层适配。全套系统用下来直接返回指定别名的Map再转JSON比专门建一堆统计实体类要省事得多。4. 安全防线登录认证与RBAC权限模型4.1 JWT登录认证流程医院后台系统的安全级别比普通管理后台要高因为涉及患者隐私数据。登录认证我用的是JWT方案流程不难但每个环节都要做对。账号密码校验通过后后端生成Token返回给前端。Token里可以包含用户id、用户名、角色编码但绝不能放密码。我用的密钥设置得足够长存入application.yml的jwt.secret配置里。拦截器负责校验每个需要认证的请求public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或token已失效); } // 解析token获取用户信息并存入ThreadLocal Claims claims JwtUtil.parseToken(token.replace(Bearer , )); UserContext.set(claims); return true; } }同时注册拦截器排除登录接口和静态资源路径。要注意的是Token过期时间我设置得比较保守默认两小时前端在请求拦截器里发现401就跳转登录页。这个方案没有做刷新机制体验上会有点粗糙但作为后台管理系统是够用的。4.2 RBAC权限模型用户-角色-菜单权限模型我用了经典的RBAC。用户与角色多对多角色与菜单多对多。登录时根据用户id查出角色再查出角色对应的菜单编码集合返回给前端。前端拿到权限编码后通过自定义指令v-permission控制按钮的显示隐藏el-button v-permissionsys:user:delete typedanger删除/el-button这个指令的实现也很简单就是在inserted钩子里从Vuex中取出当前用户的权限编码数组如果不存在该权限码就移除当前DOM元素。按钮级别权限在很多管理系统里容易被忽略但医院系统里收费员不能操作退费这类需求就必须靠权限码来控制。后端的权限控制放在Service层用一个辅助方法校验当前用户是否有某个权限码public void checkPermission(String permissionCode) { String userRole UserContext.getRoleCode(); if (!rolePermissionCache.containsKey(userRole) || !rolePermissionCache.get(userRole).contains(permissionCode)) { throw new BusinessException(403, 无权限执行该操作); } }接口层的PreAuthorize注解同样能实现但那需要引入Spring Security对于我这种自定义JWT拦截器的轻量方案直接在Service层校验反而更直观。前端隐藏按钮只是提升体验后端接口校验才是真正的安全边界。4.3 越权访问的防护细节权限系统只防角色不够垂直越权同样要防。比如一个医生登录后查挂号记录的接口传入了doctorId2而自己实际上是doctorId3如果不校验就会看到别人的数据。我在查询接口里加了一层数据归属校验通过当前登录用户id反查对应的doctorId强制用这个doctorId去查数据前端传什么参数都不能覆盖掉这个归属条件。患者查询同理患者档案信息默认只有关联本次就诊的医生和授权管理员可以查看。密码加密用的是BCrypt这个方案自带盐值每次哈希结果都不同比直接MD5安全得多。数据库里如果看到明文密码或者统一加盐的MD5那基本等于没防护。5. 部署教程本地联调到服务器上线的完整过程5.1 本地环境准备与启动顺序先把本地环境确认清楚这一套系统需要的工具版本如下JDK 1.8及以上我这边用的1.8稳定Maven 3.6Node.js 14Vue CLI项目建议14以上MySQL 5.7或8.0Redis非必需这套系统没引入启动顺序有讲究先启动MySQL和创建数据库再启动后端最后启动前端。MySQL建库建表我准备了init.sql脚本包含建库语句和初始化数据。初始化数据必须包括管理员账号和基础菜单数据否则连登录页面都进不去。后端启动时如果有端口冲突改application.yml里的server.port即可。我约定本地后端用9090端口前端用8080端口避免和默认端口撞车。前端启动前先执行npm install装依赖可能遇到版本问题常见的坑是Node版本过高导致node-sass装不上。我在项目里统一改用sassdart-sass或者直接用vue-cli默认的样式方案能少很多折腾。5.2 前端打包后如何放进SpringBoot部署方式我试过两种Nginx方案更标准但直接把前端打包文件放进SpringBoot也有其适用场景——个人项目、教学演示、没有独立Nginx环境的服务器。第一种方式前端执行npm run build生成dist目录然后上传到服务器Nginx配置静态文件根目录指向这个dist再配置一个反向代理把/api请求转发到后端9090端口。这种方式前后端完全独立升级后端不影响前端静态资源。第二种方式把dist目录里的文件复制到SpringBoot的src/main/resources/static目录下重新打包为同一个jar。这样只需部署一个进程。注意前端打包时publicPath要改为相对路径// vue.config.js module.exports { publicPath: ./, outputDir: dist }我实测中比较推荐第一种方式。前后端分离的意义就是可以独立部署、独立升级硬塞进同一个jar虽然省事但在后续维护时会很痛苦。如果只是想快速演示给朋友看第二种方式也不是不行但最好明确这只是权宜之计。5.3 服务器部署全流程服务器以LinuxCentOS 7或Ubuntu为例部署步骤基本固定安装JDK、MySQL、Nginx上传init.sql到服务器执行建库命令上传后端jar包使用nohup java -jar启动nohup java -jar hospital-admin.jar --spring.profiles.activeprod log.txt 21 确认后端进程存活curl http://localhost:9090/api/health能返回200即可上传前端dist目录到Nginx配置的目录修改Nginx配置server { listen 80; server_name your_domain_or_ip; root /www/hospital-admin-web/dist; index index.html; location /api { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }最后一定要把后端生产环境的账号密码改为强密码并修改JWT密钥千万不要把开发环境的配置直接带上线。5.4 上线后才会暴露的几个坑本地开发一切正常部署到服务器后出现了几个典型问题。一是MySQL时区问题。登录时报com.mysql.cj.exceptions.InvalidConnectionAttributeException根本原因是应用服务和数据库服务时区不一致。解决办法是在数据库连接串上显式指定jdbc:mysql://localhost:3306/hospital_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai服务器默认时区如果是UTC而你在中国不显式配置时区就会差8个小时所有时间统计全部错乱。二是Nginx部署前端后刷新404问题。VueRouter如果使用history模式刷新非首页路径时Nginx找不到对应的静态文件。解决办法是配置try_fileslocation / { try_files $uri $uri/ /index.html; }这个坑在部署单页应用时极其常见几乎每一个第一次上线的Vue项目都会遇到。三是服务器防火墙忘记开放端口浏览器访问超时。排查顺序应该是先看本机curl通不通再看安全组再检查Nginx状态。我见过太多人一上来就改代码实际只是防火墙没放行。6. 实践中踩过的坑与下一步优化方向6.1 前后端分离的隐性成本前后端分离不等于把代码拆成两个仓库就完事。实际开发中最大的隐性成本在联调和接口变更。前端假设接口返回{code: 200, data: {list: []}}后端某次调整返回了{status: 200, result: []}测试同事就报故障。这套系统的接口规范从一开始就要用统一返回体约束住我用Result类的泛型结构解决了一半问题另一半靠接口文档约定。另一个坑是前端联调环境配置多时容易乱。我推荐在项目根目录建.env.development、.env.production、.env.test三个文件分别配置不同的VUE_APP_BASE_API地址构建时自动加载对应环境变量比手动改代码科学得多。6.2 这套系统后续值得扩展的方向如果让我继续优化这套系统我的优先级如下。先把Redis加进来把医生排班、药品库存这类热点数据做缓存。挂号高峰期同一个医生号源会被大量并行查询MySQL单表单查扛扛还行但对数据库来说压力并不小。然后引入Spring Security替换自定义拦截器虽然自定义方案轻量但Security在密码策略、会话管理、CSRF防护上更成熟。不过这会增加学习成本如果项目本身不复杂自定义方案完全够用。再就是引入文件上传和预览医院场景里病历图片、检查报告单的存储是刚需这个在现有系统里是明确的扩展点。最后可以考虑把系统拆成微服务架构但我要泼一盆冷水这种规模的业务拆成微服务会带来无穷无尽的分布式事务和运维复杂度单体应用把模块边界做好就够了。业务量没上来之前微服务是大炮打蚊子。6.3 我对这类项目管理上的一些体会做这类系统要紧的其实不是技术栈本身而是能不能把一条完整的业务链路跑通。很多同学写完用户管理就停住了觉得系统做完了其实核心的挂号-接诊-开处方-收费-发药这条主链路才是真正的业务主体。我建议把主链路梳理清楚之后再回头做权限、日志、统计这些支撑功能整个系统在结构上才算闭环。我在这套系统的开发过程中反复验证了一个观点好的工程习惯比花哨技术更扛得住变动。统一返回结构能少吵很多架数据库脚本纳入版本管理能少漏很多变更部署步骤写成文档能免掉很多回忆。这些细节单个看着不起眼加在一起才是项目能顺利交付的真正原因。如果你也想拿这套系统练手建议不要只看代码跑起来就完事试着改一个模块、加一个字段、追一遍主链路的表关系收获会比想象中大很多。