搜了几个月的源码资源终于把“基于Spring Boot的疗养院管理系统的设计与实现11711”这个课题完整跑通了。如果你也正在为毕设或课设焦头烂额甚至刚拿到题还一头雾水这篇文章应该能帮你省下不少时间。做一个管理系统难度真不在编码而在拿到课题编号之后怎么把需求、表结构、接口设计、权限控制这些事一步步理清楚。我会按自己实际开发这个项目的顺序来写从业务还原到技术选型再到核心模块的落地最后把那些只有真正跑一遍才会踩到的坑也一并列出来。无论你打算照着重写还是只借鉴思路都能直接拿走用。先说一句Spring Boot 在这个场景下不是“因为流行所以选它”而是它确实能把这类单体管理系统的开发成本压到最低。这不是什么高深项目但正因为普适才更考验基本功——包括数据建模、三层划分、异常处理以及答辩时能否把每一个设计决策讲明白。1. 拿到课题编号之后先别急着建工程把“业务剧本”写出来在启动 IDE 之前我花了两天时间反复读题目。很多人拿到一个编号比如这里的 11711会直接去搜代码但这恰恰是本末倒置。课题编号往往只是题库里的一个占位符真正决定你设计好坏的是你对“疗养院管理系统”这个业务域的理解深度。1.1 疗养院和普通酒店/医院管理系统有什么本质区别疗养院既不是医院也不是酒店它的管理对象不是“订单”或“患者”而是“一段长期居住的生活”。这意味着系统要管的东西非常杂疗养人员老人/康复人员的档案、家属信息、入住合同、押金健康数据包括血压、血糖、心率、用药记录、体检报告生活服务比如床位分配、订餐、探视预约、活动安排员工管理包括护理员排班、交接班记录、考勤运营端包括账单、退费、统计报表。你完全可以把住酒店那套“房间—订单—退房”逻辑迁移过来但必须增加一条健康档案主线。我当时画了一张业务流程图核心数据流是这样的入院登记 → 分配床位 → 建立健康档案 → 周期性体检/护理记录 → 用药/餐饮/探视等日常服务 → 出院结算。这条主线直接决定了数据库里哪些表是核心表哪些表只是附属表。1.2 角色划分系统到底给谁用另一个容易被忽略的问题是角色。我一开始只设计了“管理员”和“普通用户”后来跑业务流程时发现根本不够。疗养院至少有三类使用者权限差异非常大角色核心诉求典型操作系统管理员全院运营数据系统配置维护员工账号、管理床位、查看报表、参数设置医护人员/护理员老人健康与护理流程录入体检记录、写护理日志、登记用药、查看健康档案前台/接待员入院、退院、探视接待登记入住、分配房间、来访登记、预约管理所以我最终把权限粒度控制在“角色—菜单—按钮”三层而不是简单用用户名判断。Spring Boot 中拦截器配合注解就能实现不需要引入 Spring Security 这种重武器这点在后面的权限章节会细说。2. 技术选型Spring Boot 在这类项目里到底带来了什么你不一定非要炫技但答辩时老师一定会问为什么用 Spring Boot哪怕只答三个字“约定优于配置”也远不够。你需要讲清楚它对比传统 SSM 省掉了哪些环节以及这个项目的体量为什么不需要 Spring Cloud。2.1 传统 SSM 的痛点与 Spring Boot 的解法我记得自己在大二时照着教程搭过一个 SSM 项目印象最深的就是配置文件的折磨web.xml、spring-mvc.xml、spring-mybatis.xml、数据库连接池……每个文件都要手动声明 bean漏一个就启动失败。Spring Boot 的核心价值就是把这些基础设施变成自动装配。内嵌 Tomcat不用再打 war 包丢到外部容器里starter 机制加一个依赖就相当于把一套能力Web、AOP、ORM、校验全部引入application.yml 统一管理配置不同环境用 profile 切换Actuator 提供运行期监控端点这在调试时能救命的。对单机就能跑起来的管理类系统Spring Boot 是正正好好的复杂度。盲目上微服务拆分把用户、档案、床位拆成三个服务除了增加部署难度没有实际收益。2.2 工程目录规范给后续维护和答辩留条活路目录结构决定了代码能撑到多大规模而不失控。我见过不少人把 Controller 写成上千行所有业务逻辑堆在一起后期改一个字段要全文件搜索。我的分包方式比较常规但非常稳定com.nursing.home ├── config // 配置类WebMvc、Cors、Json序列化、拦截器 ├── controller // 只做参数接收与结果封装 ├── service // 业务逻辑接口 │ └── impl // 业务逻辑实现 ├── mapper // 数据访问层接口 ├── entity // 数据库实体 ├── dto // 入参对象常配合Validated校验 ├── vo // 出参对象控制前端看到的字段 ├── common // 统一返回结果、状态码、异常类、常量 ├── aspect // 日志切面 └── utils // 工具类JWT、日期转换、文件存储实体、DTO、VO 分开这件事我一定要强调。虽然字段看起来常常一样但如果直接把数据库实体返回给前端时间和扩展都会很被动。比如后端用户表里有密码哈希值你肯定不希望这个字段出现在接口返回里。使用 Maven 构建是这个项目的默认前提。我记得初始创建项目时不需要全靠 start.spring.io 网页手动写一个最小 POM 也很值得掌握parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies记得 Spring Boot 2.7 还没完全跨到 Jakarta 命名空间如果你的 JDK 是 17建议直接上 Spring Boot 3.x 并选对应的 MyBatis 启动器。3. 数据库设计健康档案、床位与护理流程怎么建模才不会被推翻数据库是这类项目里最值得花时间的部分。我第一版表结构只设计了 12 张表做完发现缺少“用药提醒”和“探视预约”后来补了两张。我的经验是设计表的时候不要追求一次完美但要预留扩展位。3.1 核心表结构与关系以老人档案为主线贯穿所有业务梳理最终的表清单大概是这样sys_user系统用户员工账户包含账号、密码哈希、姓名、角色ID、手机号、在职状态elder_info疗养人员档案包含姓名、身份证号、家属联系方式、入院时间、状态、紧急联系人room_info / bed_info房间和床位房间有类型单人间/双人间、朝向床位有权属状态health_record体检/健康记录表每次测量或体检一行存血压、心率、血糖、身高体重等medical_record就诊/病历表存诊断结果、医嘱、药品、日期care_plan护理计划关联某个老人存护理等级、护理频次、注意事项care_log护理日志记录了每天由哪个护理员执行了哪些操作medication_reminder用药提醒存药品名称、剂量、频次、下一次提醒时间diet_order订餐/膳食订单关联老人和餐次visit_record探视登记生客/家属来访记录payment_record缴费/退费流水sys_role、sys_menu、role_menu权限三件套。这些表之间最核心的关联是elder_info 成为所有业务表的“外键源头”。比如 health_record、care_log、diet_order 都通过 elder_id 指向同一个老人。这样设计的好处是首页统计、病历回顾、费用汇总都能从老人维度一键拉出。下面是我简化后的核心关系示例CREATE TABLE elder_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, id_card VARCHAR(18) UNIQUE, phone VARCHAR(20), emergency_contact VARCHAR(50), emergency_phone VARCHAR(20), status TINYINT DEFAULT 1 COMMENT 1在院 2出院 3请假, create_time DATETIME, update_time DATETIME ); CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, systolic INT, diastolic INT, heart_rate INT, blood_glucose DECIMAL(5,2), height DECIMAL(5,1), weight DECIMAL(5,1), measure_time DATETIME, operator_id BIGINT, remark VARCHAR(500), create_time DATETIME ); CREATE TABLE bed_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, bed_no VARCHAR(20) NOT NULL, status TINYINT DEFAULT 0 COMMENT 0空闲 1已分配 2维修, elder_id BIGINT NULL );3.2 容易被低估的三个设计细节第一是软删除和审计字段。每张业务表我都加了is_deleted、create_time、update_time理由很实际如果误删一个老人的健康档案后果很麻烦。数据要能“后悔”。MySQL 里 MyBatis-Plus 的TableLogic注解可以直接支撑逻辑删除不需要在每一条 SQL 里手动加条件。第二是避免物理外键。我见过有人用 Navicat 把外键关系画得满满当当物理外键在插入更新时会带来锁竞争毕设演示时还容易出现外键约束导致的诡异报错。我更推荐保留elder_id这类逻辑外键在代码里保证数据一致性。第三是金额和体检指标字段的类型必须精确。押金、账单金额用DECIMAL(10,2)不要用double血压、血糖这些指标如果后续要做趋势统计建议直接存数值而非字符串。我第一次就把血压存成了135/85这样的字符串后来要算平均血压时欲哭无泪。正确做法是拆成systolic和diastolic两个字段。4. 核心功能落地从登录鉴权到健康档案哪些代码最值得自己写设计稿画得再好最后还是要落到代码上。以下是我认为这个系统里最核心、也最值得你亲手写一遍的三个模块。4.1 登录与权限控制拦截器 JWT不引入 Security 也够用在毕设阶段引入 Spring Security 是可以的但我个人觉得没有必要它会导致配置学习曲线陡增。用 JWT 拦截器的方案刚好能讲清楚认证和授权的本质也容易在答辩时自圆其说。流程是这样的用户提交账号密码后端用 BCrypt 校验密码哈希Spring Security 里的BCryptPasswordEncoder可以单独引出来用不需要引入整个 Security校验通过后生成 JWT把用户ID、角色编码放进去设置过期时间前端后续请求在请求头带上Authorization: Bearer token拦截器解析 token放行或拒绝。拦截器注册时最大的坑是白名单。你至少要放行登录接口、静态资源、错误路径否则前端页面都进不去Configuration public class WebMvcConfig implements WebMvcConfigurer { Resource private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns( /api/auth/login, /api/auth/logout, /error, /static/** ); } }然后根据接口路径做角色校验。比如/api/admin/**下的接口必须管理员/api/nurse/**必须是护理角色。自己封装一个RequireRole(ADMIN)注解一个 AOP 切面就能搞定比在 Controller 里写一堆 if 判断干净得多。4.2 健康档案与护理记录重点是“只追加、不覆盖”和审计健康档案模块的代码逻辑不复杂但设计理念要清晰。老人每次体检、每次量血压都应该新增一条记录而不是把上一次的数据覆盖掉。这样做的价值在于后期可以拉一条连续的数据曲线分析老人的健康趋势同时也符合医疗记录的可追溯原则。护理日志也同样。我设计的care_log表里必填的字段包括老人ID、护理员ID、护理类型翻身、换药、喂食等、护理内容、时间、老人当时的状态。这既是护理记录也是责任追溯的依据。前端页面展示时会按时间倒序展示某位老人的护理时间线方便家属查看。我写这段接口时的一个经验DTO 校验一定要做。我遇到过前端传负数身高、日期格式错误的情况如果没有NotNull和Min这类注解脏数据会直接进库。Spring Boot 的Validated配合一个统一的异常处理器可以帮你在入口处就把问题拦下来。4.3 床位分配与状态流转一个小状态机床位这块的业务逻辑是典型的“状态机”。一个床位的状态流转如下空闲 → 已分配 → 空闲退房/转房→ 维修。实现时我用了bed_info表上的status和elder_id两个字段配合。分配床位时开启事务先检查床位状态是否是空闲再更新床位状态和老人ID同时更新老人的房间信息退房时反之。如果只改床位状态不清理elder_id查询时就会出现一个床位分配给多个老人的脏数据。对这种状态流转我会在 service 层封装专门的方法而不是在 Controller 里写裸 SQLTransactional(rollbackFor Exception.class) public void assignBed(Long elderId, Long bedId) { BedInfo bed bedMapper.selectById(bedId); if (bed.getStatus() ! 0) { throw new BusinessException(该床位当前不可分配); } bed.setStatus(1); bed.setElderId(elderId); bedMapper.updateById(bed); ElderInfo elder elderMapper.selectById(elderId); elder.setRoomId(bed.getRoomId()); elderMapper.updateById(elder); }Transactional在这里必须是标配否则床位更新成功了、老人信息更新失败了数据就对不上了。5. 联调与测试阶段踩过的坑这几条排错链路值得背下来这部分我想仔细写因为真正让你成长的不是那些顺利跑通的接口而是那些让你查了两天日志的 Bug。5.1 Jackson 序列化无限递归一个典型的 StackOverflow第一次写老人详情接口时我直接用elderMapper.selectById()返回实体然后惊悚地发现接口直接报 500后台日志疯狂刷StackOverflowError。原因很简单elder_info和health_record建立了双向关联查询老人时带着健康记录列表而健康记录里又关联了老人Jackson 序列化时就像照镜子一样无限循环。排查链路大概是这样的第一步看完整异常栈确认 StackOverflowError 发生在 JSON 序列化阶段第二步检查实体类之间的关联关系第三步选择解法。我最终选择的方案是在实体关联字段上加JsonIgnore。虽然 DTO 更优雅但在毕设阶段用注解快速解决问题并把逻辑讲清楚就够了public class ElderInfo { // ... JsonIgnore private ListHealthRecord healthRecords; }还有一种情况如果你用 MyBatis-Plus 的selectPage直接返回实体列表遇到父子结构会用到一个很实用的注解JsonIgnoreProperties它能按需忽略字段。记住Controller 层返回给前端的内容越精简越好用 VO 接一层永远是最稳的。5.2 LocalDateTime 格式问题前端显示的 T 字符前后端联调时前端同事发来一张截图所有时间都变成了2025-03-14T10:30:00中间多了个“T”。如果你不在后端的application.yml里统一配置日期格式默认序列化会把 LocalDateTime 序列化成 ISO 格式这个 T 非常不友好。解决方式有两种二选一即可spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8或者在配置类里注册一个Jackson2ObjectMapperBuilderCustomizer。我建议用 yaml 方式因为它对所有 LocalDateTime 全局生效。需要注意如果你在实体上用了JsonFormat它会优先于全局配置生效所以最好统一风格。5.3 Actuator 端点暴露的安全风险与加固我在项目里引入了spring-boot-starter-actuator本意是想看看项目的健康状态但这个依赖也带来了安全风险。默认配置下/actuator会把很多敏感端点直接暴露出来。当时我部署到测试环境后顺手访问了一下/actuator/env发现环境变量、数据库连接信息全都露在外面吓出一身冷汗。暴露的端点包括env、beans、mappings、heapdump等。如果你不想让这些信息人人可见一定要做两件事management: endpoints: web: exposure: include: health,info endpoint: health: show-details: never如果决定只暴露指定端点其余全部关闭可以写成management: endpoints: web: exposure: include: health另外如果你想知道应用的实时性能数据可以在项目里整合 Micrometer 上报指标到 Prometheus 或本地监控看板。毕设阶段不用做得很复杂但答辩时提到“通过 Actuator 监控应用健康状态用 Micrometer 做指标采集”是个很实用的加分项。生产环境里Actuator 暴露策略要遵循最小化原则这是面试官很看重的一点。5.4 越权与密码明文这些问题到了测试阶段才暴露系统上线到测试环境后我用普通员工账号登录直接手动输入管理员接口地址居然也能访问。这是因为我的拦截器只校验了“是否登录”没有校验“是否有权限”。修复方案很直接在拦截器 / AOP 中根据 JWT 里的角色信息判断路径权限。PreAuthorize(hasRole(ADMIN))或者在 AOP 切面里做一个注解校验。核心思路是后端每个受保护资源都必须显式声明角色要求不能只靠前端隐藏按钮。另外密码我一开始是用 MD5 存的后来被做安全测试的同学提醒才意识到 MD5 已经不再安全彩虹表分分钟就能爆破。于是我改用 BCryptBCryptPasswordEncoder encoder new BCryptPasswordEncoder(); String hashed encoder.encode(rawPassword); // 校验时 encoder.matches(rawPassword, hashed);参与毕设评审的老师如果知道你在 2025 年还在用 MD5 存密码大概率会扣印象分。BCrypt 是标准做法自带盐值能有效地对抗暴力破解。6. 从“能跑”到“能答辩”再往前一步你还能补什么做到上面的步骤系统已经算是一个完整可演示的毕设了。但如果想让答辩更有底气、代码质量更上一层以下扩展方向可以挑一两个做。6.1 消息通知与第三方对接的扩展思路疗养院场景里用药提醒和家属通知是非常有说服力的扩展点。我当时做了用药提醒的定时任务每天按预设时间把当天需服用的药品清单推送给护理员。简单方案用 Spring Boot 的Scheduled定时扫表查询待提醒的记录进阶方案把提醒记录投递到消息队列如 Redis Stream 或 RabbitMQ异步发送短信、邮件或微信模板消息海外业务场景中也有很多人做 Firebase Cloud Messaging 来给 App 推送通知Spring Boot 做服务端只需调用 FCM 的 HTTP v1 API本质是一次 POST 请求。如果你还想做视频监控、门禁联动这类功能也可以看看大华或海康的设备 SDK通过 Spring Boot 封装成接口后网页端可以调用鉴权接口获取播放地址做实时预览、回放和云台控制。不过这条线的工作量比较大不是毕设刚需我建议把它列为“后续优化方向”在答辩 PPT 里提一嘴就够了。6.2 答辩时老师最可能追问的高频问题清单我自己答辩时被问到的问题加上后来帮学弟学妹模拟面试总结的基本集中在下面这些点Spring Boot 的自动配置原理是什么核心答法SpringBootApplication组合注解中的EnableAutoConfiguration通过META-INF/spring.factories或AutoConfiguration.imports加载候选配置类再配合ConditionalOnClass等条件注解按需装配。Maven 的构建流程有哪些阶段validate、compile、test、package、verify、install、deploy重点讲 package 阶段会执行测试并打出可执行 jar。谈谈 Spring 事务的传播机制以及Transactional失效的可能场景。答法要点同类内部调用导致代理失效、方法不是 public、异常被 try-catch 吞掉、自调用绕过 AOP 等。为什么分区设计答法要点业务解耦、查询效率、职责单一并强调单体应用不等于没有分层。如果用户量上来了系统哪里会成为瓶颈答法要点数据库连接、热点数据的缓存、静态资源分离以及日志监控。这些问题其实都在检验你是不是真的独立完成了项目。哪怕是从别人源码改造过来的也一定要把每一条核心链路在 IDE 里 Debug 一遍确保老师问“为什么这里要用事务”时你能答出真实场景。6.3 我最后做的一件事给系统加了一份“设计说明书式”的 README系统代码完成之后我额外花了一天时间整理了一篇 README内容包括项目启动步骤数据库初始化脚本、配置文件修改点、默认账号核心接口清单及调用示例表结构说明和 ER 图链接部署到云服务器的简要命令。这份 README 后来在答辩时帮了大忙因为老师现场要求我演示时我直接照着 README 一步步启动整个过程非常顺畅。很多项目代码本身写好了但演示时老师连怎么启动都不知道这是很吃亏的。代码写完只是第一步文档写清楚才算是“可交付”。对整个毕业设计流程来说代码、文档、演示三者缺一不可。我在实际开发中最大的体会是这个系统虽然挂着“Spring Boot 疗养院管理系统”的名头但它本质上是在训练你怎么把一个模糊的业务诉求翻译成清晰的表结构、接口和权限模型。认真做下来你对 Spring Boot 的掌握程度会远超只会写 CRUD 的同学。如果你正在做类似的课题最稳妥的路线就是先抄理解别人的思路再改替换业务场景最后自己造独立实现某几个核心模块。至少把登录、床位分配、健康档案这三个模块的代码逐行看懂不要整个项目全是复制粘贴——答辩被追问细节的时候是不是自己写的几句话就能试出来。 
长河君 · 2026/9/7 23:20:25 · 阅读 1.2k 基于Spring Boot的疗养院管理系统设计与实现全解析
搜了几个月的源码资源终于把“基于Spring Boot的疗养院管理系统的设计与实现11711”这个课题完整跑通了。如果你也正在为毕设或课设焦头烂额甚至刚拿到题还一头雾水这篇文章应该能帮你省下不少时间。做一个管理系统难度真不在编码而在拿到课题编号之后怎么把需求、表结构、接口设计、权限控制这些事一步步理清楚。我会按自己实际开发这个项目的顺序来写从业务还原到技术选型再到核心模块的落地最后把那些只有真正跑一遍才会踩到的坑也一并列出来。无论你打算照着重写还是只借鉴思路都能直接拿走用。先说一句Spring Boot 在这个场景下不是“因为流行所以选它”而是它确实能把这类单体管理系统的开发成本压到最低。这不是什么高深项目但正因为普适才更考验基本功——包括数据建模、三层划分、异常处理以及答辩时能否把每一个设计决策讲明白。1. 拿到课题编号之后先别急着建工程把“业务剧本”写出来在启动 IDE 之前我花了两天时间反复读题目。很多人拿到一个编号比如这里的 11711会直接去搜代码但这恰恰是本末倒置。课题编号往往只是题库里的一个占位符真正决定你设计好坏的是你对“疗养院管理系统”这个业务域的理解深度。1.1 疗养院和普通酒店/医院管理系统有什么本质区别疗养院既不是医院也不是酒店它的管理对象不是“订单”或“患者”而是“一段长期居住的生活”。这意味着系统要管的东西非常杂疗养人员老人/康复人员的档案、家属信息、入住合同、押金健康数据包括血压、血糖、心率、用药记录、体检报告生活服务比如床位分配、订餐、探视预约、活动安排员工管理包括护理员排班、交接班记录、考勤运营端包括账单、退费、统计报表。你完全可以把住酒店那套“房间—订单—退房”逻辑迁移过来但必须增加一条健康档案主线。我当时画了一张业务流程图核心数据流是这样的入院登记 → 分配床位 → 建立健康档案 → 周期性体检/护理记录 → 用药/餐饮/探视等日常服务 → 出院结算。这条主线直接决定了数据库里哪些表是核心表哪些表只是附属表。1.2 角色划分系统到底给谁用另一个容易被忽略的问题是角色。我一开始只设计了“管理员”和“普通用户”后来跑业务流程时发现根本不够。疗养院至少有三类使用者权限差异非常大角色核心诉求典型操作系统管理员全院运营数据系统配置维护员工账号、管理床位、查看报表、参数设置医护人员/护理员老人健康与护理流程录入体检记录、写护理日志、登记用药、查看健康档案前台/接待员入院、退院、探视接待登记入住、分配房间、来访登记、预约管理所以我最终把权限粒度控制在“角色—菜单—按钮”三层而不是简单用用户名判断。Spring Boot 中拦截器配合注解就能实现不需要引入 Spring Security 这种重武器这点在后面的权限章节会细说。2. 技术选型Spring Boot 在这类项目里到底带来了什么你不一定非要炫技但答辩时老师一定会问为什么用 Spring Boot哪怕只答三个字“约定优于配置”也远不够。你需要讲清楚它对比传统 SSM 省掉了哪些环节以及这个项目的体量为什么不需要 Spring Cloud。2.1 传统 SSM 的痛点与 Spring Boot 的解法我记得自己在大二时照着教程搭过一个 SSM 项目印象最深的就是配置文件的折磨web.xml、spring-mvc.xml、spring-mybatis.xml、数据库连接池……每个文件都要手动声明 bean漏一个就启动失败。Spring Boot 的核心价值就是把这些基础设施变成自动装配。内嵌 Tomcat不用再打 war 包丢到外部容器里starter 机制加一个依赖就相当于把一套能力Web、AOP、ORM、校验全部引入application.yml 统一管理配置不同环境用 profile 切换Actuator 提供运行期监控端点这在调试时能救命的。对单机就能跑起来的管理类系统Spring Boot 是正正好好的复杂度。盲目上微服务拆分把用户、档案、床位拆成三个服务除了增加部署难度没有实际收益。2.2 工程目录规范给后续维护和答辩留条活路目录结构决定了代码能撑到多大规模而不失控。我见过不少人把 Controller 写成上千行所有业务逻辑堆在一起后期改一个字段要全文件搜索。我的分包方式比较常规但非常稳定com.nursing.home ├── config // 配置类WebMvc、Cors、Json序列化、拦截器 ├── controller // 只做参数接收与结果封装 ├── service // 业务逻辑接口 │ └── impl // 业务逻辑实现 ├── mapper // 数据访问层接口 ├── entity // 数据库实体 ├── dto // 入参对象常配合Validated校验 ├── vo // 出参对象控制前端看到的字段 ├── common // 统一返回结果、状态码、异常类、常量 ├── aspect // 日志切面 └── utils // 工具类JWT、日期转换、文件存储实体、DTO、VO 分开这件事我一定要强调。虽然字段看起来常常一样但如果直接把数据库实体返回给前端时间和扩展都会很被动。比如后端用户表里有密码哈希值你肯定不希望这个字段出现在接口返回里。使用 Maven 构建是这个项目的默认前提。我记得初始创建项目时不需要全靠 start.spring.io 网页手动写一个最小 POM 也很值得掌握parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies记得 Spring Boot 2.7 还没完全跨到 Jakarta 命名空间如果你的 JDK 是 17建议直接上 Spring Boot 3.x 并选对应的 MyBatis 启动器。3. 数据库设计健康档案、床位与护理流程怎么建模才不会被推翻数据库是这类项目里最值得花时间的部分。我第一版表结构只设计了 12 张表做完发现缺少“用药提醒”和“探视预约”后来补了两张。我的经验是设计表的时候不要追求一次完美但要预留扩展位。3.1 核心表结构与关系以老人档案为主线贯穿所有业务梳理最终的表清单大概是这样sys_user系统用户员工账户包含账号、密码哈希、姓名、角色ID、手机号、在职状态elder_info疗养人员档案包含姓名、身份证号、家属联系方式、入院时间、状态、紧急联系人room_info / bed_info房间和床位房间有类型单人间/双人间、朝向床位有权属状态health_record体检/健康记录表每次测量或体检一行存血压、心率、血糖、身高体重等medical_record就诊/病历表存诊断结果、医嘱、药品、日期care_plan护理计划关联某个老人存护理等级、护理频次、注意事项care_log护理日志记录了每天由哪个护理员执行了哪些操作medication_reminder用药提醒存药品名称、剂量、频次、下一次提醒时间diet_order订餐/膳食订单关联老人和餐次visit_record探视登记生客/家属来访记录payment_record缴费/退费流水sys_role、sys_menu、role_menu权限三件套。这些表之间最核心的关联是elder_info 成为所有业务表的“外键源头”。比如 health_record、care_log、diet_order 都通过 elder_id 指向同一个老人。这样设计的好处是首页统计、病历回顾、费用汇总都能从老人维度一键拉出。下面是我简化后的核心关系示例CREATE TABLE elder_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, id_card VARCHAR(18) UNIQUE, phone VARCHAR(20), emergency_contact VARCHAR(50), emergency_phone VARCHAR(20), status TINYINT DEFAULT 1 COMMENT 1在院 2出院 3请假, create_time DATETIME, update_time DATETIME ); CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, systolic INT, diastolic INT, heart_rate INT, blood_glucose DECIMAL(5,2), height DECIMAL(5,1), weight DECIMAL(5,1), measure_time DATETIME, operator_id BIGINT, remark VARCHAR(500), create_time DATETIME ); CREATE TABLE bed_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, bed_no VARCHAR(20) NOT NULL, status TINYINT DEFAULT 0 COMMENT 0空闲 1已分配 2维修, elder_id BIGINT NULL );3.2 容易被低估的三个设计细节第一是软删除和审计字段。每张业务表我都加了is_deleted、create_time、update_time理由很实际如果误删一个老人的健康档案后果很麻烦。数据要能“后悔”。MySQL 里 MyBatis-Plus 的TableLogic注解可以直接支撑逻辑删除不需要在每一条 SQL 里手动加条件。第二是避免物理外键。我见过有人用 Navicat 把外键关系画得满满当当物理外键在插入更新时会带来锁竞争毕设演示时还容易出现外键约束导致的诡异报错。我更推荐保留elder_id这类逻辑外键在代码里保证数据一致性。第三是金额和体检指标字段的类型必须精确。押金、账单金额用DECIMAL(10,2)不要用double血压、血糖这些指标如果后续要做趋势统计建议直接存数值而非字符串。我第一次就把血压存成了135/85这样的字符串后来要算平均血压时欲哭无泪。正确做法是拆成systolic和diastolic两个字段。4. 核心功能落地从登录鉴权到健康档案哪些代码最值得自己写设计稿画得再好最后还是要落到代码上。以下是我认为这个系统里最核心、也最值得你亲手写一遍的三个模块。4.1 登录与权限控制拦截器 JWT不引入 Security 也够用在毕设阶段引入 Spring Security 是可以的但我个人觉得没有必要它会导致配置学习曲线陡增。用 JWT 拦截器的方案刚好能讲清楚认证和授权的本质也容易在答辩时自圆其说。流程是这样的用户提交账号密码后端用 BCrypt 校验密码哈希Spring Security 里的BCryptPasswordEncoder可以单独引出来用不需要引入整个 Security校验通过后生成 JWT把用户ID、角色编码放进去设置过期时间前端后续请求在请求头带上Authorization: Bearer token拦截器解析 token放行或拒绝。拦截器注册时最大的坑是白名单。你至少要放行登录接口、静态资源、错误路径否则前端页面都进不去Configuration public class WebMvcConfig implements WebMvcConfigurer { Resource private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns( /api/auth/login, /api/auth/logout, /error, /static/** ); } }然后根据接口路径做角色校验。比如/api/admin/**下的接口必须管理员/api/nurse/**必须是护理角色。自己封装一个RequireRole(ADMIN)注解一个 AOP 切面就能搞定比在 Controller 里写一堆 if 判断干净得多。4.2 健康档案与护理记录重点是“只追加、不覆盖”和审计健康档案模块的代码逻辑不复杂但设计理念要清晰。老人每次体检、每次量血压都应该新增一条记录而不是把上一次的数据覆盖掉。这样做的价值在于后期可以拉一条连续的数据曲线分析老人的健康趋势同时也符合医疗记录的可追溯原则。护理日志也同样。我设计的care_log表里必填的字段包括老人ID、护理员ID、护理类型翻身、换药、喂食等、护理内容、时间、老人当时的状态。这既是护理记录也是责任追溯的依据。前端页面展示时会按时间倒序展示某位老人的护理时间线方便家属查看。我写这段接口时的一个经验DTO 校验一定要做。我遇到过前端传负数身高、日期格式错误的情况如果没有NotNull和Min这类注解脏数据会直接进库。Spring Boot 的Validated配合一个统一的异常处理器可以帮你在入口处就把问题拦下来。4.3 床位分配与状态流转一个小状态机床位这块的业务逻辑是典型的“状态机”。一个床位的状态流转如下空闲 → 已分配 → 空闲退房/转房→ 维修。实现时我用了bed_info表上的status和elder_id两个字段配合。分配床位时开启事务先检查床位状态是否是空闲再更新床位状态和老人ID同时更新老人的房间信息退房时反之。如果只改床位状态不清理elder_id查询时就会出现一个床位分配给多个老人的脏数据。对这种状态流转我会在 service 层封装专门的方法而不是在 Controller 里写裸 SQLTransactional(rollbackFor Exception.class) public void assignBed(Long elderId, Long bedId) { BedInfo bed bedMapper.selectById(bedId); if (bed.getStatus() ! 0) { throw new BusinessException(该床位当前不可分配); } bed.setStatus(1); bed.setElderId(elderId); bedMapper.updateById(bed); ElderInfo elder elderMapper.selectById(elderId); elder.setRoomId(bed.getRoomId()); elderMapper.updateById(elder); }Transactional在这里必须是标配否则床位更新成功了、老人信息更新失败了数据就对不上了。5. 联调与测试阶段踩过的坑这几条排错链路值得背下来这部分我想仔细写因为真正让你成长的不是那些顺利跑通的接口而是那些让你查了两天日志的 Bug。5.1 Jackson 序列化无限递归一个典型的 StackOverflow第一次写老人详情接口时我直接用elderMapper.selectById()返回实体然后惊悚地发现接口直接报 500后台日志疯狂刷StackOverflowError。原因很简单elder_info和health_record建立了双向关联查询老人时带着健康记录列表而健康记录里又关联了老人Jackson 序列化时就像照镜子一样无限循环。排查链路大概是这样的第一步看完整异常栈确认 StackOverflowError 发生在 JSON 序列化阶段第二步检查实体类之间的关联关系第三步选择解法。我最终选择的方案是在实体关联字段上加JsonIgnore。虽然 DTO 更优雅但在毕设阶段用注解快速解决问题并把逻辑讲清楚就够了public class ElderInfo { // ... JsonIgnore private ListHealthRecord healthRecords; }还有一种情况如果你用 MyBatis-Plus 的selectPage直接返回实体列表遇到父子结构会用到一个很实用的注解JsonIgnoreProperties它能按需忽略字段。记住Controller 层返回给前端的内容越精简越好用 VO 接一层永远是最稳的。5.2 LocalDateTime 格式问题前端显示的 T 字符前后端联调时前端同事发来一张截图所有时间都变成了2025-03-14T10:30:00中间多了个“T”。如果你不在后端的application.yml里统一配置日期格式默认序列化会把 LocalDateTime 序列化成 ISO 格式这个 T 非常不友好。解决方式有两种二选一即可spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8或者在配置类里注册一个Jackson2ObjectMapperBuilderCustomizer。我建议用 yaml 方式因为它对所有 LocalDateTime 全局生效。需要注意如果你在实体上用了JsonFormat它会优先于全局配置生效所以最好统一风格。5.3 Actuator 端点暴露的安全风险与加固我在项目里引入了spring-boot-starter-actuator本意是想看看项目的健康状态但这个依赖也带来了安全风险。默认配置下/actuator会把很多敏感端点直接暴露出来。当时我部署到测试环境后顺手访问了一下/actuator/env发现环境变量、数据库连接信息全都露在外面吓出一身冷汗。暴露的端点包括env、beans、mappings、heapdump等。如果你不想让这些信息人人可见一定要做两件事management: endpoints: web: exposure: include: health,info endpoint: health: show-details: never如果决定只暴露指定端点其余全部关闭可以写成management: endpoints: web: exposure: include: health另外如果你想知道应用的实时性能数据可以在项目里整合 Micrometer 上报指标到 Prometheus 或本地监控看板。毕设阶段不用做得很复杂但答辩时提到“通过 Actuator 监控应用健康状态用 Micrometer 做指标采集”是个很实用的加分项。生产环境里Actuator 暴露策略要遵循最小化原则这是面试官很看重的一点。5.4 越权与密码明文这些问题到了测试阶段才暴露系统上线到测试环境后我用普通员工账号登录直接手动输入管理员接口地址居然也能访问。这是因为我的拦截器只校验了“是否登录”没有校验“是否有权限”。修复方案很直接在拦截器 / AOP 中根据 JWT 里的角色信息判断路径权限。PreAuthorize(hasRole(ADMIN))或者在 AOP 切面里做一个注解校验。核心思路是后端每个受保护资源都必须显式声明角色要求不能只靠前端隐藏按钮。另外密码我一开始是用 MD5 存的后来被做安全测试的同学提醒才意识到 MD5 已经不再安全彩虹表分分钟就能爆破。于是我改用 BCryptBCryptPasswordEncoder encoder new BCryptPasswordEncoder(); String hashed encoder.encode(rawPassword); // 校验时 encoder.matches(rawPassword, hashed);参与毕设评审的老师如果知道你在 2025 年还在用 MD5 存密码大概率会扣印象分。BCrypt 是标准做法自带盐值能有效地对抗暴力破解。6. 从“能跑”到“能答辩”再往前一步你还能补什么做到上面的步骤系统已经算是一个完整可演示的毕设了。但如果想让答辩更有底气、代码质量更上一层以下扩展方向可以挑一两个做。6.1 消息通知与第三方对接的扩展思路疗养院场景里用药提醒和家属通知是非常有说服力的扩展点。我当时做了用药提醒的定时任务每天按预设时间把当天需服用的药品清单推送给护理员。简单方案用 Spring Boot 的Scheduled定时扫表查询待提醒的记录进阶方案把提醒记录投递到消息队列如 Redis Stream 或 RabbitMQ异步发送短信、邮件或微信模板消息海外业务场景中也有很多人做 Firebase Cloud Messaging 来给 App 推送通知Spring Boot 做服务端只需调用 FCM 的 HTTP v1 API本质是一次 POST 请求。如果你还想做视频监控、门禁联动这类功能也可以看看大华或海康的设备 SDK通过 Spring Boot 封装成接口后网页端可以调用鉴权接口获取播放地址做实时预览、回放和云台控制。不过这条线的工作量比较大不是毕设刚需我建议把它列为“后续优化方向”在答辩 PPT 里提一嘴就够了。6.2 答辩时老师最可能追问的高频问题清单我自己答辩时被问到的问题加上后来帮学弟学妹模拟面试总结的基本集中在下面这些点Spring Boot 的自动配置原理是什么核心答法SpringBootApplication组合注解中的EnableAutoConfiguration通过META-INF/spring.factories或AutoConfiguration.imports加载候选配置类再配合ConditionalOnClass等条件注解按需装配。Maven 的构建流程有哪些阶段validate、compile、test、package、verify、install、deploy重点讲 package 阶段会执行测试并打出可执行 jar。谈谈 Spring 事务的传播机制以及Transactional失效的可能场景。答法要点同类内部调用导致代理失效、方法不是 public、异常被 try-catch 吞掉、自调用绕过 AOP 等。为什么分区设计答法要点业务解耦、查询效率、职责单一并强调单体应用不等于没有分层。如果用户量上来了系统哪里会成为瓶颈答法要点数据库连接、热点数据的缓存、静态资源分离以及日志监控。这些问题其实都在检验你是不是真的独立完成了项目。哪怕是从别人源码改造过来的也一定要把每一条核心链路在 IDE 里 Debug 一遍确保老师问“为什么这里要用事务”时你能答出真实场景。6.3 我最后做的一件事给系统加了一份“设计说明书式”的 README系统代码完成之后我额外花了一天时间整理了一篇 README内容包括项目启动步骤数据库初始化脚本、配置文件修改点、默认账号核心接口清单及调用示例表结构说明和 ER 图链接部署到云服务器的简要命令。这份 README 后来在答辩时帮了大忙因为老师现场要求我演示时我直接照着 README 一步步启动整个过程非常顺畅。很多项目代码本身写好了但演示时老师连怎么启动都不知道这是很吃亏的。代码写完只是第一步文档写清楚才算是“可交付”。对整个毕业设计流程来说代码、文档、演示三者缺一不可。我在实际开发中最大的体会是这个系统虽然挂着“Spring Boot 疗养院管理系统”的名头但它本质上是在训练你怎么把一个模糊的业务诉求翻译成清晰的表结构、接口和权限模型。认真做下来你对 Spring Boot 的掌握程度会远超只会写 CRUD 的同学。如果你正在做类似的课题最稳妥的路线就是先抄理解别人的思路再改替换业务场景最后自己造独立实现某几个核心模块。至少把登录、床位分配、健康档案这三个模块的代码逐行看懂不要整个项目全是复制粘贴——答辩被追问细节的时候是不是自己写的几句话就能试出来。