SpringBoot+Vue敬老院管理系统：从数据库设计到部署排错全解析

我最初接触敬老院管理系统这个项目，是帮一个熟人机构的信息科搭内部系统。需求一听并不复杂：老人档案、床位、护理记录、费用结算，再加点统计报表。但真正把“基于SpringBoot+Vue+MyBatis+MySQL”这套组合从零跑到稳定上线，中间还是踩了不少坑。如果你也准备做类似的管理系统，或者正在为毕业设计、小企业信息化项目找一套清晰可复用的方案，这篇文章应该对你有用。

我会从业务拆分、技术选型、建表与接口实现、权限控制、部署排错这几个角度，把整套系统怎么设计和写代码讲透。里面涉及的核心代码片段，都是我实际调试通过的写法。完整源码不方便直接贴，但思路和关键实现给到，你可以照着搭出自己的版本。

1. 项目整体设计与功能模块拆解

1.1 敬老院业务到底要管什么

敬老院管理系统，听起来像是一个普通的CRUD项目，但真正深入之后会发现，业务核心其实围绕“老人”这个主体形成了一条完整的数据链：入院登记、健康评估、床位分配、护理计划、日常护理记录、费用产生、退住归档。每个环节都有关联关系，数据还必须能回查。这和纯电商后台的商品管理有本质区别，做的时候最好先按生命周期来梳理，而不是先写页面。

我最终把系统拆成了这几个核心模块：

• 老人档案管理：老人的基本信息、身份证、入住状态、紧急联系人、既往病史。
• 床位管理：楼栋、楼层、房间、床位四级结构，床位状态必须区分空闲、占用、停用。
• 入住退住管理：办理入院、分配床位、退住结算、档案归档。
• 健康与护理管理：护理计划、护理记录、用药提醒、健康巡检数据。
• 费用管理：床位费、护理费、餐饮费、退费记录，按月生成账单。
• 系统管理：用户、角色、菜单权限、操作日志。

这几个模块之间不是孤立的。举例来说，老人档案里的“入住状态”字段，会直接影响床位分配接口能不能执行。护理记录表里的每一条数据，又关联到费用结算时护理等级的单价计算。早期我图省事，把状态散落在各个表里，结果统计入住率的时候要对很多表做联表查询，非常痛苦。后面统一用“入住记录表”作为业务主表，老人档案只保留最新状态字段，才把逻辑理顺。

1.2 核心流程与状态流转设计

把生命周期理清楚后，下一步就是定义状态。我给入住流程设计了一个简单的状态机：

• 待入住：老人档案已创建，尚未办理入住，也没有床位。
• 在住：已分配床位，正在接受护理服务。
• 退住：已经结算离院，床位释放，档案归档。

这个状态机看起来简单，但对系统的约束作用非常大。比如，办理退住时，如果护理记录里还有未完成的用药提醒，系统会弹提示；如果费用账单未结清，退住接口会直接抛异常。状态设计一定要在编码前定好，否则后面做接口校验会越写越乱。

另外，费用模块我建议独立出来，不混在老人档案表里。费用记录应关联入住记录而不是直接关联老人，因为同一个老人可能多次入住，每次的价格方案和护理等级都可能不同。这一点是实测中比较坑的地方，最早我的费用表直接关联老人编号，导致二次入住的账单全乱套了。

2. 技术选型逻辑与工程结构设计

2.1 为什么还是SpringBoot+Vue这套组合

2025年回看，Java后端可选的框架其实不少，但这个项目场景下，SpringBoot依然是最稳妥的选择。社区生态成熟、招聘市场认可度高、部署运维资料多。Vue做后台管理系统，配合现成的组件库，开发效率确实比传统JQuery时代高了一个数量级。

具体版本我建议这样选：如果服务器环境还是JDK 8，那就用SpringBoot 2.7.x，稳定且兼容性最好。如果环境是新的，直接用JDK 17 + SpringBoot 3.x也完全可以，注意javax命名空间要替换成jakarta。前端方面，Vue 3 + Vite + Element Plus是2025年的主流组合，别再用Vue 2了，部分依赖已经停止维护。

选MyBatis而不是MyBatis-Plus或者JPA，我个人的理由是：这类管理系统报表查询特别多，SQL的可控性非常重要。MyBatis让你能把复杂联表查询和统计逻辑直接写在XML里，调优也直观。JPA虽然开发快，但遇到多条件动态查询时拼Specification非常难受。如果你实在想提升效率，可以用MyBatis-Plus的通用Mapper来减少单表CRUD代码，但复杂查询依旧建议手写XML。

2.2 MySQL表结构与字符集设计的几个细节

数据库这一层，最容易被忽略的就是字符集。我接手过的几个项目，很多早期的库用的还是utf8。在保存老人备注、药品说明等文本时，一旦遇到生僻字或者表情符号，直接报“Incorrect string value”错误。新建数据库时一定要指定utf8mb4，排序规则用utf8mb4_general_ci或utf8mb4_unicode_ci都可以。

另外就是时间字段的统一。我的习惯是：所有业务表都加create_time和update_time两个字段，由后端统一填充，不让前端传。查询条件涉及时间的，统一按LocalDateTime处理。数据库连接串里必须加上serverTimezone=Asia/Shanghai，否则在使用某些连接池组件时，会出现中国时区下午8点被存成下午1点的问题。这个坑后面排错部分我会详细说。

2.3 前后端工程结构与接口请求约定

后端我采用标准的四层结构：Controller接收参数、Service处理业务、Mapper访问数据库、Entity映射表。Controller层应该保持薄，只做参数校验和结果封装；复杂的业务判断放Service层，方便复用和写单元测试。

前端目录我习惯这样组织：

• src/api：按模块封装的请求函数
• src/router：路由表，配置动态路由和守卫
• src/views：页面组件，按模块分目录
• src/components：通用组件，比如老人信息选择器、床位状态标签等

前后端接口约定也很重要。所有接口统一返回一个Result对象，包含code、message、data三个字段。code为200表示成功，其他为业务异常。这样前端可以统一在axios拦截器里处理错误提示，不需要每个接口单独写错误判断。分页请求统一用current和size参数，返回数据结构里带上total，这样前端封装的Pagination组件可以直接用。

3. 核心模块的数据库设计与接口实现

3.1 老人档案模块：从建表到接口完整实现

老人档案是整个系统的地基，我先给出实际运行过的建表SQL，你可以对照理解：

CREATE TABLE `elderly_info` ( `id` bigint NOT NULL AUTO_INCREMENT, `elder_no` varchar(32) NOT NULL COMMENT '老人编号', `name` varchar(50) NOT NULL COMMENT '姓名', `gender` tinyint NOT NULL COMMENT '1男 2女', `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号', `birth_date` date DEFAULT NULL COMMENT '出生日期', `phone` varchar(20) DEFAULT NULL COMMENT '本人电话', `health_status` varchar(255) DEFAULT NULL COMMENT '当前健康状况', `allergy_history` varchar(500) DEFAULT NULL COMMENT '过敏史', `emergency_contact` varchar(50) DEFAULT NULL COMMENT '紧急联系人', `emergency_phone` varchar(20) DEFAULT NULL COMMENT '紧急联系电话', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待入住 1在住 2退住', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_elder_no` (`elder_no`), KEY `idx_name` (`name`), KEY `idx_id_card` (`id_card`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='老人基本信息表';

有几个字段值得说明：elder_no建议前端生成时就用一个规则，比如年份加四位序号，20250001。不要用数据库自增id直接展示，毕竟老人编号可能会在单据、工牌上出现，自增id不安全也不专业。id_card加索引是因为后续查询老人、核验身份非常频繁，但身份证号属于敏感信息，接口返回时需要做脱敏处理，比如只返回前6位和后4位。

后端新增老人的接口核心逻辑大致是这样：

@PostMapping("/elderly") public Result<Void> addElderly(@RequestBody @Valid ElderlyDTO dto) { // 身份证号重复校验 ElderlyInfo exist = elderlyMapper.selectByIdCard(dto.getIdCard()); if (exist != null) { return Result.error(400, "该身份证号已存在档案"); } // 生成老人编号 String elderNo = elderlyService.generateElderNo(); // 保存并处理敏感字段脱敏日志 return elderlyService.saveElderly(dto, elderNo); }

这里我想特别提醒一个操作经验：在保存档案的同时，一定要做日志记录。敬老院的系统将来可能面临家属查询“什么时候登记的、谁登记的、改过什么信息”这类需求，所以我在日志表里记录了每一次关键操作的操作用户、操作类型、操作时间、修改前后的内容摘要。前期多写这点代码，后期能省大量扯皮的时间。

3.2 入住与床位分配：事务和并发状态控制

入住办理是这个系统最容易出并发问题的地方。试想两个前台同时给两位老人分配同一张空闲床位，如果不加控制，就会出现一张床住两个人的尴尬场面。我采用的办法是“数据库乐观更新 + 事务”双重保证。

核心SQL分两步：先查询符合条件的空闲床位，然后执行更新时带上状态条件：

UPDATE bed_info SET status = 1, elder_id = #{elderId} WHERE id = #{bedId} AND status = 0

执行这条UPDATE语句后，如果返回影响行数为0，说明床位已经被别人占用，事务回滚并提示用户换一张床。这种方式比先查后改要可靠得多，因为它把“检查状态”和“修改状态”合并成了一个原子操作。

入住办理的Service方法我加上了@Transactional注解，同一个事务里完成床位状态更新、入住记录创建、老人状态同步更新三个动作。这里必须强调：事务只对RuntimeException和回滚策略生效，我在业务代码里如果判断入住时间晚于当前时间这类不合法情况，会主动抛出运行时异常，确保事务正确回滚。

3.3 护理记录与健康档案的实现要点

护理记录表关联老人和护理员，记录内容包含护理项目、护理内容、执行时间。我设计时把护理计划和护理记录分成了两张表，因为计划是预定的，记录是实际执行的，两者不一定完全一致。如果只用一张表，做“计划完成率”统计时会非常麻烦。

护理记录表核心字段如下：

• elder_id：关联老人
• nurse_id：执行护理员
• care_type：护理类型，比如生活照料、医疗护理、康复训练
• content：具体的护理内容
• record_time：执行时间
• status：正常/已作废

健康档案部分，我选择定期体检数据和日常巡检数据分开存储。体检数据半年一次，量少但结构固定；巡检数据可能每天都有，量大会持续增长。如果混在一张表，查询历史趋势时索引效率会下降。分开后，巡检表定时备份，大表查询也不至于拖慢整个系统。这个设计思路对于数据量达到几千条之后才开始明显，但建议一开始就按这个方式建表，不然后面拆表迁移非常痛苦。

4. 权限控制与系统安全实践

4.1 基于角色的权限模型设计

敬老院管理系统的使用者包括管理员、前台工作人员、护理人员、护士、财务人员等。不同角色能看到的菜单和能操作的按钮必须严格区分。我没有引入太重的权限框架，用的是经典的RBAC模型：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。

实际实施时，我用一个统一鉴权注解配合拦截器实现接口权限控制。大体流程是：用户登录成功后，后端生成一个令牌（这里用的JWT）返回给前端，前端存到本地存储中。每次请求时，axios拦截器会在请求头里带上令牌。后端自定义一个拦截器，拦截所有请求，解析令牌获得用户信息和角色编码，再根据当前请求的路径判断是否允许访问。

拦截器实现中优先设置白名单：登录接口、验证码接口、静态资源等不需要鉴权。其余接口全部走Token校验。对比过把权限散落在每个Controller注解里的做法，这种集中式拦截器更容易维护，新增接口时只要按约定配置权限标识即可，不容易漏。

4.2 前端路由守卫与按钮级权限控制

前端部分，路由守卫是必须的。Vue Router的beforeEach钩子里，判断本地是否存有Token。没有Token且去的是非白名单页面，直接跳转登录页。有Token但访问的路由不在当前用户角色菜单列表里，就跳转404页面。

按钮级权限我用的是自定义指令v-permission。在登录接口返回用户菜单和按钮权限标识后，存到全局状态管理里。页面渲染按钮时，指令内部判断权限标识是否存在，不存在则直接移除该按钮的DOM节点。这样能防止前端看到无权操作的按钮，但要注意，前端按钮控制只负责体验和掩盖，真正安全边界在后端拦截器里，前端做得再花哨，后端不校验一样是白搭。

4.3 密码与敏感信息的处理

用户密码在数据库里必须是加密后的密文，这里没有争议。我建议直接用BCrypt加密，同一个密码每次生成的哈希值都不同，安全性比MD5加盐要好很多，而且是Spring Security自带支持的，不需要额外引包。

关于老人证件号码的脱敏，我踩过一次教训：在联调阶段，前端说不需要身份证号，只要姓名和年龄，我就直接把整个对象返回了，虽然前端没展示，但浏览器控制台里能看见完整号码。后来所有接口返回值一律经过脱敏处理，身份证、手机号这类字段在Service层就处理好再封装返回。另外日志打印时也要注意，不要直接打印完整参数。

5. 实操踩坑与问题排查实录

5.1 日期时间与序列化的坑

最常见的坑就是前端传生日或者入住日期，后端用LocalDate接收时报错，或者解析出来日期少了8小时。这不是某一个框架的问题，而是整个链路里JSON处理、数据库驱动、连接配置三层必须同时正确。

我最终的处理方案是：全局配置Jackson序列化规则，统一将LocalDate格式化为yyyy-MM-dd，LocalDateTime格式化为yyyy-MM-dd HH:mm:ss。同时连接串里加serverTimezone=Asia/Shanghai，让MySQL与JVM时间保持一致。改完这堆配置之后，日期问题才彻底消停。建议你也先做一个专门的日期测试接口，把新增、修改、查询、列表四种场景都测一遍，不要等页面联调时再来翻问题。

5.2 分页查询性能优化

列表页用PageHelper分页，数据量小的时候速度很快。但当护理记录表数据量增长之后，发现列表越翻越慢。排查发现罪魁祸首是分页的count查询对一张100万行的大表做了全表扫描。我给常用的查询条件加了联合索引，比如查询护理记录时，条件通常是elder_id加record_time范围，于是建了(elder_id, record_time)联合索引。同时把列表页默认时间范围限定为最近三个月，避免一进来就全量统计。

另外PageHelper有个经典使用误区：必须紧接着查询语句调用startPage方法，中间不能有其他数据库操作，否则分页参数会被后续查询消费掉，导致拿到的数据不对。这个坑特别隐蔽，我建议业务代码里封装一个统一的分页查询方法，所有列表查询都走这个方法，避免每个Service重新写一遍导致漏用规范。

5.3 前端Vue打包后刷新404

项目上线后，前端部署到Nginx，发现只要在登录后刷新页面，就会404。原因是Vue Router启用了History模式，而后端Nginx没有做对应的try_files配置。解决办法是在Nginx的server配置里加一段：

location / { try_files $uri $uri/ /index.html; }

这个配置的含义是：如果请求的路径在服务器上找不到对应文件，就回退到index.html，把路由交给前端处理。改成这个之后刷新页面就不再404了。开发环境下没这个问题，因为Vite开发服务器已经处理过了。这类部署问题，建议在写正式上线手册的时候就写进去，不要每次换环境部署都重新踩一遍。

5.4 常见问题速查表

我把实际项目中遇到的高频问题整理成一张速查表，你看看能不能对号入座：

5.5 老人档案逻辑删除与数据追溯

还有一个小点容易被忽略：老人档案在系统里不能被物理删除。最初因为测试方便，我做的是物理删除，后来发现只要删掉一位老人的档案，他之前的护理记录、费用记录全都变成无主数据，统计报表直接漏数据。后来改成逻辑删除，在表里加了一个deleted字段，默认0，删除时置为1。所有查询都默认过滤deleted=1的数据。这个改动非常关键，可能短时间内看不出差别，但系统上线半年后再查历史报表，你会庆幸自己当时没偷懒。

事务和回滚逻辑也配套做了调整。删除单人必须同时检查名下是否有未结清费用和未归档的入住记录，有的话提示“存在未处理账单，无法删除”。这样就在数据层把业务规则给约束住了，界面层的校验只是辅助。

结语

这个敬老院管理系统做到后面，我觉得技术层面的东西，反而没有业务理解和细节把控重要。SpringBoot和Vue的套路网上到处都是，但一套系统能不能真正用起来，靠的是状态机设计是否严谨、床位并发分配是否可靠、敏感信息有没有脱敏、分页查询能不能撑住数据增长。你在动手前，先把业务主流程认认真真走一遍，在纸上画出各模块的联系，再对照我上面这些踩坑点去设计实现，会少走很多弯路。

最后分享一个小技巧：如果你也是第一次做这类项目，建议先亲手把数据库表建出来，再用接口调试工具逐个验证接口，最后再写前端页面。这个顺序看着不酷，但查错效率极高。我吃过几次亏之后才明白，页面联调时的问题，十有八九出在接口和数据结构上，前端只是最后一个暴露问题的地方。