前后端分离养老院管理系统：SpringBoot+Vue架构设计与部署实战

“前后端分离养老院管理系统”这个标题，乍一看像是某个课程设计或者毕业设计项目，但如果你真的把整套源码跑起来、把部署流程走一遍，会发现它其实是一个很完整的业务系统样板——涉及角色权限、床位管理、护理记录、费用核算、健康档案这些真实业务模块。我前阵子刚好帮一个做智慧养老服务的团队审过一套同类系统，发现这类项目踩坑的点其实非常集中：前端接口对接混乱、MyBatis关联查询写不好、跨域配置漏掉、部署时数据库编码出问题。这篇就把我从这套养老院管理系统中拆解出来的核心设计、代码实现和部署细节整理出来，适合正在做管理系统类项目的开发者参考，也适合想快速搭一套可用后台的前端或全栈同学。

1. 项目整体设计与架构拆解

1.1 这套系统解决了什么问题

养老院管理系统的业务场景和普通的增删改查系统不太一样。它涉及的实体多、状态变化频繁、权限层级分明。举个具体的例子：一个老人从入院到退住，要经历入住登记、体检建档、床位分配、护理等级评估、费用记账、家属探访预约、健康状况跟踪这些环节。每个环节都涉及不同的角色——前台接待、护士、护工、财务、院长、家属——如果不用系统管理，全靠表格和微信群，信息基本是碎的。

这套后端+前端完全分离的架构，核心就是把这些业务流程从线下搬到线上，并且做到权限可控、数据可查、流程可追溯。后端只负责提供接口和数据逻辑，前端只负责页面展示和交互，两者通过JSON格式的接口通信。这样带来的直接好处是：前端可以单独替换（比如以后想换移动端，接口不用动），后端可以单独扩展（比如接入智慧硬件设备），开发和联调也能并行推进。

1.2 为什么选SpringBoot + Vue这套组合

选型这个问题，很多人在项目开始前纠结很久。这套系统用SpringBoot + Vue + MyBatis + MySQL，其实是目前中小型管理系统最成熟的组合之一，理由很直接：

• SpringBoot：省去大量XML配置，内嵌Tomcat，打成一个jar就能跑。对养老院这类业务逻辑偏重、并发量不高的系统来说，性能完全够用。
• Vue：响应式数据和组件化开发的体验比传统的JSP、Thymeleaf好了不止一个档次。页面状态管理（比如老人列表的筛选条件、床位图的选中状态）用Vue的data和computed处理非常顺手。
• MyBatis：复杂查询写SQL更灵活，尤其是多表关联查询（老人+床位+护理等级）可以手动控制SQL，不会像JPA那样自动生成一堆低效的联表语句。
• MySQL：开源、稳定、运维成本低，配合Navicat或MySQL Workbench管理数据非常方便。

这套技术栈对开发者最友好的地方是：生态成熟，遇到问题网上资料多，招人也好招。对团队来说，上手成本低，后期维护的压力也比较小。

1.3 前后端分离的核心协作约定

前后端分离项目最关键的不是技术本身，而是接口约定。这套系统里前后端通信有几个约定非常值得一提：

• 统一响应结构：后端所有接口返回固定JSON格式，包含状态码、消息、数据三部分。前端拿到响应后先判断状态码，再决定是正常渲染数据还是弹出错误提示。
• Token鉴权：登录成功后后端签发Token，前端存在本地存储里，之后每个请求都在请求头里带上。后端通过拦截器验证Token，没带或过期就直接返回401。
• 接口路径规范：统一以/api开头，模块名用复数名词，比如/api/elders、/api/beds。这样前端封装请求模块的时候可以完全对应后端Controller的名字，不会找不到接口。

这套约定看起来简单，但实际项目里很多团队就是因为没定好规范，前端写一个路径、后端定义另一个路径，联调时来回改，费时又容易出错。

2. 核心功能模块与数据库设计

2.1 业务模块的划分思路

养老院管理系统的业务模块，我拆解下来核心是六个：老人档案、床位管理、护理记录、费用管理、员工管理、系统设置。其中老人档案是主数据，床位和护理记录都围绕老人生成，费用模块则从护理记录和入住天数自动计算。

每个模块的页面结构都遵循同一个模式：列表页（带搜索、分页）+ 新增/编辑弹窗 + 详情页。这种模式的好处是前端代码复用率高，后端接口设计也可以统一成列表查询、根据ID查详情、新增、更新、删除这几类标准接口。系统里还配了登录页、首页仪表盘、个人信息页和密码修改，形成一套完整可用的后台管理体系。

2.2 数据库表的关联关系设计

数据库设计是这个系统里含金量比较高的部分。核心表我列一下：

• sys_user（系统用户表）：存储登录账号、密码（加密存储）、角色ID、是否启用。人员类型包括管理员、护士、护工、财务等。
• elder_info（老人档案表）：姓名、性别、身份证号、家属联系方式、入住日期、健康状态、紧急联系人。这张表关联了床位ID和护理等级ID。
• bed_info（床位表）：楼栋、楼层、房间号、床位号、床位状态（空闲/占用/维修）。养老院管理里床位状态非常关键，决定新老人能不能入住。
• nursing_level（护理等级表）：等级名称、护理内容说明、每日护理费用。等级不同，费用标准也不一样。
• nursing_record（护理记录表）：每天由护工录入，记录老人当日护理情况，比如体温、血压、饮食、用药、特殊护理操作。
• fee_record（费用记录表）：每月或定期生成，包含床位费、护理费、餐饮费、医疗费，支持实收金额和欠费状态。
• visit_record（探访记录表）：家属探访登记，记录来访人、与被探访老人关系、来访时间、离开时间。

表与表之间关系很清晰：老人表关联床位表、护理等级表、家属表；护理记录表关联老人表和护工ID；费用表关联老人表。这样设计的好处是数据不冗余、查询链路短，比如查询某个老人的详情时，通过老人表的外键就能直接关联出床位号、护理等级和所有护理记录。

2.3 角色权限的设计要点

权限设计上，这套系统用的是比较经典的RBAC模式（基于角色的访问控制）。角色分成超级管理员、护工、护士、财务、家属（只读）几类。后端在做接口设计时不光是写CRUD，每个接口都限制了角色：

• 超级管理员：全部权限，包括员工账号管理、床位信息维护、系统参数配置。
• 护工：只能查看自己负责的老人列表，录入护理记录，修改个人密码。
• 护士：可以查看全部老人健康档案，维护护理等级，审核护理记录。
• 财务：只能访问费用相关接口，生成收费单，标记实收/未收。

这个设计思路在代码层面就是通过SpringBoot的拦截器或注解实现的。实际开发中，拦截器里面判断用户角色，再决定是否放行请求，比在每个Controller里写if判断要干净得多。

3. 后端SpringBoot核心技术实现

3.1 项目目录结构与启动流程

后端项目结构按功能分包，看起来很简单，但对新手来说很友好，一眼就能找到入口：

src/main/java/com/example/eldercare ├── controller # 接口层，接收前端请求 ├── service # 业务逻辑层，处理具体业务 ├── mapper # MyBatis数据访问接口 ├── entity # 数据库实体类 ├── config # 配置类（跨域、拦截器等） ├── common # 通用类（统一返回结果、Token工具等） └── EldercareApplication.java # 启动类

启动流程也很好理解：启动类运行后，SpringBoot自动扫描所有配置，加载数据库连接，然后启动内嵌Tomcat。前端请求到达Controller，Controller调用Service处理业务逻辑，Service调用Mapper和数据库交互，结果一层层返回，最后包装成统一JSON结构响应给前端。

3.2 统一响应结构与全局异常处理

这点值得单独拿出来讲，因为统一的返回结构能直接决定前端联调的效率。系统里定义了一个通用Result类，格式是这样的：

{ "code": 200, // 状态码：200成功，400业务错误，401未登录，500系统异常 "message": "操作成功", "data": { } // 具体业务数据，可以是对象或列表 }

所有Controller的返回值都封装成这个Result对象。前端拿到响应后，只需要检查code字段，不需要在response里找半天数据。

配套的还有全局异常处理：用@RestControllerAdvice捕获所有异常，统一转换成Result格式返回。这一招很实用，因为没做全局异常处理的话，后端一报错前端拿到的就是一堆看不懂的堆栈信息，开发体验很差。做了全局异常捕获后，即使代码里有bug，前端也只会收到"系统异常，请稍后再试"，不会直接暴露接口内部结构。

3.3 MyBatis映射与动态SQL的实战技巧

MyBatis在这套系统里的应用，最有学习价值的其实是动态SQL。养老院的老人列表页一般都有筛选条件：按姓名模糊查询、按护理等级筛选、按入住时间段筛选——但用户不见得每次都会填所有条件。如果为每种情况写一套SQL，代码会非常臃肿。

MyBatis的<if>标签就是为这个场景设计的。比如查询老人列表的SQL大致长这样：

<select id="findElderList" resultType="com.example.eldercare.entity.ElderInfo"> SELECT * FROM elder_info <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="nursingLevelId != null"> AND nursing_level_id = #{nursingLevelId} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

这样用户填了姓名就按姓名查，选了护理等级就按等级查，什么都不填就返回全部。这套写法的好处很明显：一个方法处理多种查询组合，SQL逻辑一目了然，而且能有效防止SQL注入，因为所有参数都是通过预编译的#{}传入的。

3.4 Token登录鉴权与密码加密

登录模块是整个系统安全性的第一道门，处理不好后面全是漏洞。这套系统的实现思路值得参考：

• 用户输入账号密码后，后端先查询用户是否存在，然后用BCrypt算法校验密码（不是MD5或者明文比对，BCrypt每次加密结果不同，而且自带盐值，安全性高很多）。
• 校验通过后，用JWT生成Token，Token里面存了用户ID、用户名、角色这些信息，设置7天有效期。
• 后续所有请求都在请求头Authorization带上Token，后端通过拦截器统一解析Token，拿到用户信息后放入请求上下文。
• 如果Token校验失败或过期，拦截器直接返回401，前端收到401就跳转登录页。

这套机制的实战价值在于：后端不需要在数据库里存Session，服务重启用户也不用重新登录，扩展成多实例部署时天然支持水平扩展，不会因为Session不同步导致登录失效。

4. 前端Vue页面与交互实现

4.1 前端项目结构与路由配置

前端项目同样按功能拆分，结构很标准：

src/ ├── api/ # 接口请求模块，每个模块对应后端一类接口 ├── assets/ # 静态资源 ├── components/ # 公共组件（分页、弹窗、上传等） ├── router/ # Vue Router路由配置 ├── store/ # Vuex状态管理（用户信息、Token等） ├── views/ # 页面组件（登录、首页、老人管理等） └── App.vue

路由配置里用到了路由守卫——这是保护页面安全的关键。前端路由守卫的作用是：判断用户是否已登录（有没有Token），没登录就强制跳转到登录页。页面权限也通过路由元信息控制，管理员能访问的路由，普通护士访问时会直接跳转到无权限提示页。

4.2 Axios请求封装与拦截器

前端请求封装这块，系统里做得比较完善，直接可以抄作业的思路是这样的：创建axios实例，设置基础URL为/api，配置超时时间，然后添加请求拦截器和响应拦截器。请求拦截器负责在每次请求的header里带上Token，响应拦截器负责统一处理响应数据：

// 请求拦截器 service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) // 响应拦截器 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 => { // 处理HTTP错误，比如401跳登录页 if (error.response.status === 401) { router.push('/login') } Message.error('请求失败，请检查网络') return Promise.reject(error) } )

封装的好处是：每个页面组件在调用接口时只需要关注业务数据，不需要每次写鉴权逻辑、错误处理逻辑，代码量直接砍掉一半以上。

4.3 核心页面的交互设计

系统里几个核心页面的交互设计也相当典型，值得抄作业：

• 床位管理页面：用可视化卡片展示床位状态，绿色表示空闲、红色表示占用、灰色表示维修。点击空床位弹出老人入住表单，点击已占用床位弹出老人信息和退住操作。这个交互比传统表格直观太多，养老院的前台工作人员几乎不需要培训就能上手。
• 护理记录录入页：护工选择自己负责的老人，然后录入当天各项护理数据。页面用表单组件按区域分组，提交后自动刷新当日记录列表，还能看到今天的录入进度（已录入多少人、未录入多少人）。
• 费用管理页：财务人员选择老人、选择计费周期，系统根据床位费和护理费单价自动计算出总费用，支持手动追加项目，然后生成费用单据。这里前端用到了计算属性，单价和数量改变时总价会实时重新计算，体验很流畅。
• 首页仪表盘：展示今日入住人数、空床数量、今日护理记录数、本月收入等统计卡片。后端提供聚合统计接口，前端用图表组件（比如ECharts）展示趋势图，院长打开系统第一眼就能看到全局状态。

5. 完整部署流程与关键配置

5.1 本地开发环境准备

先把开发环境说清楚，这套系统的部署其实是分两部分的：本地跑起来调试，以及生产环境部署。本地环境你需要准备的工具是：

• JDK 1.8或以上版本（建议直接用JDK 1.8，兼容性最稳）
• Maven 3.6+（后端依赖管理）
• Node.js 14+（前端构建）
• MySQL 5.7或8.0（数据库）
• Navicat或MySQL Workbench（可选，数据库可视化工具）
• IDEA（后端开发）和VS Code（前端开发）

安装这些工具本身不难，但版本匹配问题经常把人卡住。我个人建议用MySQL 8.0搭配JDK 1.8的组合，兼容性测试过很多次，基本没踩过坑。MySQL 5.7也完全可以，只是连接驱动的配置稍有区别，后面会提到。

5.2 数据库初始化步骤

数据库这块最容易出错的是字符集。养老院系统里老人姓名、地址这些字段都是中文，如果字符集没设置成utf8mb4，入库就会出现乱码。建议建库时直接执行：

CREATE DATABASE elder_care DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后使用项目中提供的SQL脚本文件导入表结构和初始数据。脚本里通常会包含管理员账号的初始密码（经过BCrypt加密），导入后直接用管理员账号登录系统，第一步建议把初始密码改掉。

如果导入后发现表里的中文都是问号，基本就是字符集问题，排查方向：连接串有没有加characterEncoding=utf8参数、表字符集是不是utf8mb4、数据库客户端默认字符集是否正确。

5.3 后端打包与配置调整

后端配置文件application.yml里有几个关键项需要根据自己环境调整：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/elder_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

这里有个高频坑：MySQL 8.0的驱动是com.mysql.cj.jdbc.Driver，MySQL 5.7的是com.mysql.jdbc.Driver。用错驱动，启动时会直接报数据库连接失败。另外如果数据库服务器设置了时区，连接串里的serverTimezone一定要配置，不然会报时区错误。

配置改好后，在项目根目录执行：

mvn clean package -DskipTests

打包完成后target目录下会生成一个eldercare-0.0.1-SNAPSHOT.jar，这就是后端可执行文件。启动命令很简单：

java -jar eldercare-0.0.1-SNAPSHOT.jar

看到日志里出现Started EldercareApplication就说明后端启动成功了，浏览器访问http://localhost:8080/api/xxx即可测试接口。

5.4 前端构建与Nginx部署

前端部署的第一步是修改API请求地址。开发环境前端通过代理解决跨域问题，生产环境则需要把请求地址指向后端服务器。通常前端项目vue.config.js里会配置代理，生产构建前改.env.production文件：

VUE_APP_BASE_URL=http://你的服务器IP:8080

然后执行：

npm install npm run build

构建完成后会在项目目录生成dist文件夹，把dist里面的内容部署到Nginx的html目录下。Nginx还需要配置反向代理，把/api开头的请求转发到后端服务，同时解决前端路由history模式的刷新404问题：

server { listen 80; server_name your_domain.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }

try_files那行是history模式下必须的配置，不加的话刷新页面会报404。前端部署这一套搞明白后，以后部署任何Vue项目的后台系统都可以复用这套Nginx配置。

5.5 生产环境部署注意事项

如果是要部署到云服务器，有几个细节千万别漏：

• 数据库远程访问授权：默认情况下MySQL只允许本机连接，需要给后端服务器的IP授权才能访问，或者后端和数据库在同一台服务器上就不用额外配置。
• 防火墙端口：后端8080端口和前端80端口需要在安全组里放行。很多人服务都启动了，浏览器访问不了，最后发现是安全组没开端口。
• 日志文件配置：生产环境建议在启动命令里加上日志输出路径，方便排查问题：

java -jar eldercare-0.0.1-SNAPSHOT.jar > /var/log/eldercare.log 2>&1 &

• 进程守护：用nohup（上面命令已包含）或者注册成systemd服务，防止误关终端后服务就停了。如果服务器内存够，也可以装个宝塔面板之类的工具做可视化进程管理，能省不少事。

6. 常见问题排查与开发经验总结

6.1 高频问题速查表

开发部署这套系统的过程中，下面这些问题出现频率最高：

6.2 跨域与接口联调踩坑记录

前后端分离项目里跨域问题几乎必踩。开发环境下，前端跑在http://localhost:9528（Vue默认端口），后端跑在http://localhost:8080，两个端口不一样，浏览器就会发起跨域请求。后端的解决方式是配置一个CORS过滤器：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:9528"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

这里有个细节很容易坑到人：setAllowCredentials(true)配置了允许携带凭证后，前端请求就必须使用相对路径的axios封装方式，不能用随便找的接口测试工具直接测，否则会因为Origin不一致被拦截。联调阶段最稳妥的方式还是用Nginx代理，这样前端请求是同源的，不涉及跨域问题。

6.3 代码层面的优化建议

整个系统跑通之后，如果还想继续优化，我基于实际经验给几个提升方向：

• 数据量大了之后，老人列表和费用记录这种高频查询的表一定要加索引，特别是在外键字段和创建时间字段上。加索引对查询性能的提升是肉眼可见的，不加的话数据到几万条就会明显变慢。
• 图片上传功能，老人档案里的证件照、体检报告扫描件，建议存到独立的对象存储服务里，数据库只存URL地址，不要把图片转成Base64存数据库，否则数据库体积膨胀很快，查询性能也会受影响。
• 操作日志，系统上线后建议加上关键操作的日志记录。养老院是涉及人身安全和收费的行业，出纠纷时有没有日志就是两回事。用AOP切面统一记录操作人和操作时间，侵入性很小。
• 数据备份，MySQL数据库每天做一次自动备份，保留最近7天。养老院的数据是持续产生的，丢了就真的找不回来。写个cron脚本定时跑mysqldump，成本很低但价值极高。

6.4 二次开发的可扩展方向

这套系统最让我觉得有价值的地方在于它的扩展性。跑通源码之后，后面可以加的东西非常多：

• 健康监测对接：现在很多养老院会配智能手环、体征监测设备，后端加一个设备数据接收接口，老人的心率、血压就能实时入库并在前端大屏展示。
• 移动端适配：护工大部分时间在老人房间和公共区域活动，不太可能在电脑前录护理记录。做一个微信小程序或企业微信端，让护工用手机拍照、语音录入护理记录，使用率会大幅提升。
• 家属端开放：给家属开一个只读端口，能在手机上看到老人的每日护理记录、探访预约、费用账单，能显著提升养老院的服务满意度和信任感。
• 数据分析报表：基于现有的费用、入住率、护理记录数据，生成月度经营报表、护理质量分析，这些对养老院管理层做决策非常有用。

做了这么多年管理系统相关的项目，我的体会是：技术栈其实只是工具，真正花时间的是理解业务逻辑和把细节做得像样子。这套养老院系统在业务理解和代码规范性上找到了一个很不错的平衡点，从架构设计到部署文档都很完整。尤其是权限设计、统一响应结构、MyBatis动态SQL这块，换个场景（比如医院管理系统、物业管理系统、教务系统）照样能用同一套思路。如果你正在做一个前后端分离的管理系统，最值得借鉴的其实是它的结构规范和接口约定，这部分才是真正省事的东西。