简介：在Java Web开发中，Spring Boot凭借自动配置和生态优势成为企业级应用的主流框架，也是毕业设计的高频选题方向。以智慧养老平台为例，系统围绕养老机构的信息化管理需求，构建了长者档案、健康管理、护理任务、费用账单等核心业务闭环。基于RBAC权限模型实现管理员、员工、家属三类角色的差异化数据访问，并结合MyBatis-Plus完成多表关联与聚合查询，通过JWT或Session机制保障登录安全。项目采用Spring Boot 3 + Thymeleaf + MySQL技术栈，兼顾开发效率与答辩演示效果。本文从系统设计、数据库建模、核心功能实现到论文写作与答辩准备，完整拆解一个可落地的Web系统项目，为准备Java毕业设计的读者提供可复用的工程实践参考，帮助提升项目的完整度与讲解能力。 又到了毕设开题和赶工的高峰期，后台每天都有人问我同一句话：“Java 毕业设计到底做什么方向，做完好答辩，代码量适中，还能写出篇幅充足的论文？” 如果你也在为这个头疼，我建议你认真看看基于Spring Boot Web的智慧养老平台这个方向。它不是一个让你非要做成人工智能下凡的“高概念”项目，而是一个业务链完整、模块边界清晰、技术栈主流、演示效果好，并且能稳稳支撑起毕业论文和答辩PPT的经典Web系统选题。
这篇项目实录，脱胎于我辅导过的多个同款毕设项目。标题后缀里的“毕业论文+PPT（附源代码+演示视频）”，说白了就是一套完整的毕设交付组合。我会把选题思路、功能设计、技术选型、数据库建模、核心编码、论文写作和答辩准备一整条链路拆开讲透。适合三类人：Java方向大四学生、准备做Web项目的毕设新手，以及已经拿到某套源码但不知道怎么去讲、怎么去改的小伙伴。
1. 毕业设计选题的定位：为什么“智慧养老平台”正中评审老师的下怀
很多学生做毕业设计有个误区：题目越高大上，答辩越稳。我见过最离谱的题目是“基于区块链的智慧养老金融监管平台”，结果开题报告都写不满两页。作为过来人，我告诉你，毕业设计评审老师看重的永远是三件事：题目有现实背景、系统有完整业务闭环、论文能写清楚你怎么实现的。智慧养老平台在这三点上几乎是满分答案。
1.1 这类选题的天然优势
先说背景。老龄化是当下绕不开的社会议题，国家政策层面不断推动智慧养老、社区养老、机构养老的信息化建设。你在论文绪论里随便找几篇政策文件和行业报告，就能写出像模像样的“研究背景与意义”，不需要虚构，不需要吹牛，所有论据都是公开可查的。
再说评审视角。评委老师每天要看几十个“图书管理系统”“网上商城系统”，已经严重审美疲劳了。养老平台自带一层“人文关怀”滤镜，给人的第一印象就是有社会价值，不是单纯为了凑学分做的玩具。开题答辩的时候你只要说一句“本课题针对养老机构日常管理中的信息孤岛、健康档案缺失、家属沟通不畅等痛点”，老师的兴趣就已经被勾起来了，后面的追问难度会自动降半级。
第三个优势是项目功能规模“可大可小”，完全由你自己掌控。时间紧就往收敛了做，只保留入住管理、健康档案、护理记录、家属查看这四条主线；时间充裕就往上加数据分析可视化、费用自动结算、护工排班等等。这种弹性空间特别适合毕设这种“既要有量又不能失控”的场景。
1.2 一套完整业务闭环长什么样
我把智慧养老平台的标准业务闭环抽象成一句话：老人入住机构，机构建立档案并分配床位，护工按排班计划日常护理并上传健康数据，系统根据健康数据产生预警，家属通过平台实时查看老人状态，最后机构根据护理项目和床位生成费用账单。
用大白话翻译成系统功能就是：
- 管理员维护系统的用户、角色、菜单权限；
- 前台接待人员登记老人信息、分配床位、建立健康档案；
- 护工登录后查看今日排班、录入老人体征数据、提交护理记录；
- 系统自动比对体征阈值，超标的生成异常提醒；
- 家属用绑定账号登录，只看得到自家老人的档案和近况；
- 财务人员根据入住时长和护理项目生成账单，完成费用结算。
这个闭环里，每种角色都有明确的操作界面，数据之间互相引用，论文里的业务流程图、用例图、时序图都不用硬编，照着这个闭环画就行。而且最妙的是，闭环内的每一步都对应一个具体的数据库表和Controller接口，写的时候一点都不会乱。
2. 系统功能设计：先把“业务流程”跑通，再谈功能菜单
每次看到有人急着写代码，我都想按住他先聊十分钟流程。智慧养老平台这种管理系统，功能设计必须从角色和流程出发，而不是从菜单表出发。菜单只是流程的外壳，流程才是系统的骨架。
2.1 机构侧核心模块拆解
按照业务闭环，机构侧至少需要五个模块，我把每个模块的关键操作点和数据库落点一起列出来，方便你后期直接对着建表：
| 模块名称 | 核心操作 | 对应数据表 |
|---|---|---|
| 系统管理 | 用户增删改查、角色分配、菜单权限 | sys_user、sys_role、sys_menu |
| 长者档案管理 | 登记长者信息、维护家属、上传照片、修改状态 | elder、family_link |
| 床位与入住管理 | 房间维护、床位分配、入住/退住登记 | room、bed、checkin_record |
| 健康管理 | 体征数据录入、历史曲线、异常预警 | health_record、health_alert |
| 护理与费用管理 | 排班、护理任务、费用项配置、账单生成 | care_task、fee_item、fee_bill |
你在答辩时能拍着胸脯讲清楚的模块，有三四个就够用了。别贪多，每个模块做得扎实一点，好过菜单列表一堆但每个都是半成品。我辅导过的学生里，挂掉的大多数不是因为做得少，而是因为做了一堆自己都说不清逻辑的功能。
2.2 家属端怎么设计才能讲出亮点
家属端是智慧养老平台区别于普通管理系统的灵魂，也是你论文里能写“平台特色”的地方。设计思路很朴素：家属不是机构员工，不需要看到全部菜单，只需要看到“我家老人”的信息。
所以家属端的权限粒度要落到数据行上。一个家属账号登录后，我只能查询到与自己绑定的老人档案、最近健康记录、护理记录和费用账单。这个“数据权限”的设计是一个很好的加分项，答辩老师大概率会问“家属为什么看不到别的老人”，你可以理直气壮地回答“用了数据权限过滤，查询时强制带上家庭成员绑定表的条件”。
2.3 三层权限模型：超管、机构员工、家属
权限设计我强烈建议用RBAC（基于角色的访问控制）模型，这是管理系统类毕设的标配，也是论文里的固定考点。最少做三个角色：
- 超级管理员（admin）：拥有全部菜单权限，可以管理用户和角色；
- 机构员工（员工角色可以细分护工、护士、财务）：根据岗位分配菜单权限，护工只看护理相关的菜单；
- 家属（family）：登录后进家属专属页面，只能看绑定老人的数据。
后端接口上，角色决定能访问哪个接口，数据归属决定能看到哪一行数据。前者用Spring Security或拦截器做，后者在Service层写条件过滤。这两层想清楚了，权限相关的代码就不会写成一坨浆糊。
3. 技术选型与工程结构：Spring Boot 3 + MyBatis-Plus，为什么不建议毕业设计强行上前后端分离
技术选型这块，我要给你泼一盆冷水：除非你前端功底非常强，或者导师明确要求，否则别在毕设里强行做前后端分离。Spring Boot + Thymeleaf服务端渲染的单体应用，才是多数人平稳落地的正确姿势。
3.1 技术选型的核心取舍逻辑
我用一个表帮你看清楚利弊：
| 选型方案 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|
| Spring Boot + Thymeleaf + AdminLTE | 部署简单、开发快、传统答辩接受度高 | 前后端耦合、交互体验一般 | 大多数学生 |
| Spring Boot + Vue3 前后端分离 | 技术栈新、简历好看 | 要处理跨域、Token、打包部署、开发链路长 | 前端熟练或导师要求 |
| JSP + Servlet | 老教材路线 | 代码维护差、写起来很痛苦 | 学校硬性要求 |
我辅导的多数学生，最后都走了Spring Boot 3 + MyBatis-Plus + MySQL 8 + Thymeleaf + AdminLTE这条路。Thymeleaf的好处是它可以在HTML页面里直接用th:each语法渲染数据，不需要单独写接口文档再联调，一个周末就能把增删改查页面全部打通。
Spring Boot 3.x 是我个人比较推荐的版本，JDK 17 + Spring Boot 3 已经是目前企业主流方向，论文里写“基于最新稳定版本开发”也更有说服力。ORM框架选MyBatis-Plus而不是原生MyBatis，理由是它自带分页插件、逻辑删除、代码生成器，能省掉大量重复的CRUD代码，让你把时间花在业务讲解上。
3.2 工程目录结构必须体现分层思想
答辩时老师经常冷不丁问一句“你的项目目录是怎么分的”。如果你给他看一个所有逻辑全塞在Controller里的项目，基本等于自杀。一个合格的毕设工程目录至少要长这样：
com.example.eldercare ├── controller // 接口层，接收参数、返回Result ├── service // 业务层，核心逻辑都在这里 │ └── impl ├── mapper // 数据访问层，继承BaseMapper ├── entity // 数据库实体 ├── dto // 页面交互对象，避免直接暴露实体 ├── config // 配置类，比如SecurityConfig、WebMvcConfig ├── common // 公共类，Result统一返回、全局异常处理 └── utils // 工具类，比如JWT工具、日期工具这个分层结构不是摆设。它的意义在于：当老师在答辩现场要求你“改一个功能”，你能快速定位到对应层。比如我要把“健康阈值”从配置文件读取，那你应该直接去service层加代码，而不是在Controller里翻半天。分层清晰本身就是一种代码质量，这种软实力会在论文的系统设计章节里被放大体现。
3.3 核心依赖与配置文件参考
pom.xml里建议引入这几个核心依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.25</version> </dependency>application.yml里要注意几个点：数据库连接串必须带serverTimezone=Asia/Shanghai和useUnicode=true&characterEncoding=utf8，不然本地连数据库必然踩时区和中文乱码的坑。文件上传大小限制也要预留，因为做长者头像上传的时候默认1MB会不够用：
spring: datasource: url: jdbc:mysql://localhost:3306/elder_care?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 10MB mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 04. 数据库设计：六张核心表，串起整个平台
数据库是毕设项目的“地基”，也是论文里必须出现ER图的部分。我给你梳理出六张核心表，这几张表关系理清楚了，系统等于完成了一半。
4.1 六张核心表的字段设计要点
第一个是用户表 sys_user。字段不用多，user_id、username、password（BCrypt加密存储）、real_name、phone、role_type（用来区分员工还是家属）、status、deleted。逻辑删除字段必须加，这是你的加分项。
第二个是长者表 elder。elder_id、name、gender、birth_date、id_card、phone、health_status（健康/慢病/失能半失能）、room_id、bed_id、checkin_status（在住/退住）、create_time。这里把房间和床位做成两个字段而不是一张表，是为了方便后续做按楼层和按房型的统计。
第三个是家属绑定表 family_link。link_id、elder_id、user_id、relation（父子/母女/其他）、is_primary。这张表是家属端数据权限的关键。
第四个是健康记录表 health_record。record_id、elder_id、nurse_id、temperature、blood_pressure_high、blood_pressure_low、heart_rate、record_time、remark。这里用一个宽表存多个体征字段，简单直接，做时间范围查询和画折线图都方便。
第五个是护理任务表 care_task。task_id、elder_id、nurse_id、task_type（翻身/喂药/洗漱/康复训练）、task_time、status（待执行/已完成/已取消）、finish_time。这张表支撑起来的是“今日待办”和“护理统计”两个核心页面。
第六个是费用账单表 fee_bill。bill_id、elder_id、bill_month、bed_fee、care_fee、meal_fee、total_amount、pay_status、create_time。费用表要冗余一个total_amount字段，避免每次查看都现场计算，这在论文里可以写成“空间换时间的查询优化思路”。
4.2 多表关联与统计查询的两种思路
业务上最复杂的查询是“家属查看老人近况”，它要关联四张表：family_link找到家属绑定的老人，elder查询老人基本信息，health_record取最近体征，care_task取最近护理记录。写的时候有两个办法：
第一种是MyBatis-Plus的条件构造器分开查，在Service层组装成一个VO返回给前端。好处是每条SQL都很简单，出了问题容易定位；坏处是多查几次数据库，但毕设规模下性能差异不敏感。
第二种是一张大的联表SQL一次性查出来。如果项目里已经有了XML文件，可以用自定义SQL实现。我更推荐把联表逻辑放在Service层用方法装配，因为答辩时你能讲清楚“为什么要分步查询”，而不是被别人质疑“这条SQL连了五张表，索引怎么设计的”。
统计类需求，比如“近7天健康状况统计”“本月费用合计”，建议直接用Mapper里的聚合查询：
SELECT DATE(record_time) AS day, AVG(heart_rate) AS avg_heart_rate, MAX(blood_pressure_high) AS max_bp_high FROM health_record WHERE elder_id = #{elderId} AND record_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(record_time)这种SQL在系统实现章节里贴出来，比一百行业务代码更有说服力。
5. 核心功能实现：从登录鉴权到健康档案登记的完整链路
功能实现这个环节，我不打算把每个模块的代码都贴一遍，那不现实也没必要。我更想讲四个真正卡住多数人的实现点：登录鉴权、Excel批量导入、健康预警、文件上传。这四个点覆盖了后端开发里最有含金量的技术细节，也是答辩时老师最爱深挖的地方。
5.1 登录鉴权：用Spring Security + JWT，还是用拦截器？
关于登录鉴权，我见过两种主流做法：Spring Security + JWT，或者简单的HandlerInterceptor拦截器。先说结论：如果项目本身是服务端渲染的Thymeleaf，我更推荐只写一个拦截器做登录校验，因为页面跳转类系统用JWT是自找麻烦；如果你的系统做成了前后端分离，那就老老实实用Spring Security + JWT。
JWT的核心逻辑是用户登录成功后，服务端生成一个带过期时间的Token字符串返回给前端，前端每次请求都把它放在请求头里，后端过滤器解析Token并获取当前用户身份。核心代码给你一个简化版本：
public class JwtUtil { private static final SecretKey KEY = Keys.hmacShaKeyFor("eldercare2024secretkeyeldercare2024".getBytes()); public static String generateToken(Integer userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(KEY) .build() .parseClaimsJws(token) .getBody(); } }这里有一个大坑，所有第一次写JWT的学生都踩过：key.getBytes()默认生成的秘钥长度可能不够，导致运行时抛WeakKeyException。解决方法是像上面一样，人为构造一个长度超过256位的字节数组，或者用Keys.secretKeyFor(SignatureAlgorithm.HS256)自动生成。
如果你的系统是Thymeleaf渲染，没有前后端分离，那建议不要引入JWT，直接用HttpSession保存登录用户信息，再写一个拦截器校验session中有没有user对象。这种方式代码量最少，答辩时也没有技术漏洞，老师问起来你就说“单体应用使用Session，状态由服务端管理更安全”。
5.2 一键导入长者档案：用EasyExcel批量录入
长者档案维护最烦人的场景是机构从Excel表格迁移老数据。如果系统里几十个老人信息靠手工一条条新增，光数据录入就要录一天。所以我在项目里给管理员加了一个“批量导入”功能，用阿里巴巴的EasyExcel实现。
使用步骤很简单：
- 前端提供一个文件上传控件，选择.xlsx模板文件；
- 后端Controller接收MultipartFile；
- 用EasyExcel的
read方法把文件解析成实体列表； - 遍历列表，逐条校验身份证号格式、手机号格式、必填字段；
- 校验通过的数据插入elder表，校验失败的记录收集错误原因，最后把导入结果返回给前端。
解析代码核心就这一行：
List<ElderImportModel> list = EasyExcel.read(inputStream) .head(ElderImportModel.class) .sheet() .doReadSync();这里最容易出错的是日期格式和表头名不匹配。Excel里的“出生日期”列是yyyy-MM-dd格式，而实体字段是LocalDate，需要加注解指定格式：
@ExcelProperty(value = "出生日期", converter = LocalDateStringConverter.class) private LocalDate birthDate;导入功能做完以后，你在论文里可以写“通过数据导入功能，平台解决了原始业务数据冷启动迁移的难题”。答辩老师一听到“冷启动”这种专业词汇，好感度直接拉升一个档次。
5.3 健康预警：阈值判断不能只写在页面里
健康预警是整个系统的“智能感”来源，也是论文最有技术含量的亮点。比如体温高于37.3℃、血压低压高于90、高压高于140、心率高于100或低于60，都应该触发异常提醒。
最简单的方案是在录入健康记录时，在Service层写一套阈值判断逻辑，一旦超限就往health_alert表插入一条预警记录，同时在前端健康页面采用红色高亮显示。这套逻辑你应该封装成一个单独的HealthAlertService，而不是散落在Controller里：
public void checkHealthAlert(HealthRecord record) { List<String> warnings = new ArrayList<>(); if (record.getTemperature() != null && record.getTemperature() >= 37.3) { warnings.add("体温偏高：" + record.getTemperature()); } if (record.getBloodPressureHigh() != null && record.getBloodPressureHigh() >= 140) { warnings.add("收缩压偏高：" + record.getBloodPressureHigh()); } if (record.getHeartRate() != null && (record.getHeartRate() >= 100 || record.getHeartRate() <= 60)) { warnings.add("心率异常：" + record.getHeartRate()); } if (!warnings.isEmpty()) { alertMapper.insert(new HealthAlert(record.getElderId(), String.join(";", warnings), 0)); } }更进阶一点的做法是把阈值配置放到sys_config表里，运行时可修改。这个做法答辩加分极其明显，因为老师会觉得“你这个平台不是写死的，是可以让业务人员自己维护规则的”。当然，实现成本也不高，不就是从配置文件换成查表嘛，但讲出来的效果完全不是一个级别。
5.4 长者头像上传的本地存储方案
文件上传这个小功能，每年都有学生问。Spring Boot里接收文件就是MultipartFile，但存到哪里、怎么访问，很多人第一次都会搞混。
推荐的做法是存到本地磁盘的固定目录，比如D:/eldercare/upload/，然后把这个目录映射成Web访问路径。在WebMvcConfig里加一行配置：
@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:D:/eldercare/upload/"); } }这样前端显示头像时，直接写/upload/20240815_xxxx.jpg就能访问到图片。上传时为了避免文件名冲突，用时间戳 + UUID重命名，比如：
String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = System.currentTimeMillis() + "_" + UUID.randomUUID() + ext; file.transferTo(new File(uploadDir, fileName));这里有一个容易忽略的地方：生产环境部署路径和本地开发路径不一样，所以上传目录最好配置在application.yml里，用@Value("${file.upload-dir}")注入。可千万别把D:/xxx这种绝对路径直接写在代码里，不然部署到服务器上必挂无疑。
6. 论文、PPT、演示视频：让导师从“能跑”看到“会讲”
项目做完只算完成一半，剩下的一半是写论文、做PPT、录视频这三件套。很多学生代码写得很溜，一写论文就挤牙膏。其实这三样东西全是套模板的活，关键是知道每一部分该填什么。
6.1 毕业论文的章节划分与写作顺序
论文结构建议沿用国内高校通用的七章标准：
| 章节 | 写作要点 | 建议篇幅 |
|---|---|---|
| 第一章 绪论 | 老龄化背景、国内外研究现状、研究意义 | 5-6页 |
| 第二章 相关技术介绍 | Spring Boot、MyBatis-Plus、MySQL、Thymeleaf | 4-5页 |
| 第三章 需求分析 | 角色分析、用例图、功能需求、非功能需求 | 6-8页 |
| 第四章 系统设计 | 总体架构、功能模块设计、数据库ER图、表设计 | 8-10页 |
| 第五章 系统实现 | 每个核心功能的截图+关键代码+实现思路 | 10-12页 |
| 第六章 系统测试 | 功能测试用例表、结果分析 | 3-5页 |
| 第七章 总结与展望 | 完成内容、存在的不足、改进方向 | 2页 |
我特别想提醒你写作顺序：先写第三章需求分析和第四章系统设计，再写第五章实现，最后写第一章绪论。因为设计章节的内容从你建的数据库表和画的原型图里扒就行，写起来最轻松；绪论反而最难写，放在最后解决掉，反而有充裕的时间打磨。
系统测试这一章不能写得像记流水账。学会用测试用例表格：用例编号、测试模块、前置条件、输入数据、预期结果、实际结果、是否通过。挑6到8个典型用例放进去，比如“管理员新增长者后页面显示是否正常”“家属端是否可以跨权限查看其他老人数据”，这样测试章节看上去就像真的做过功能测试一样。
6.2 答辩PPT的关键页面设计
答辩PPT控制在10到12页，别超过15页。页面的结构是固定的，我从几十场答辩复盘里总结出来的最优结构：
- 封面页：题目 + 姓名 + 学号 + 指导教师
- 研究背景页：老龄化数据 + 社会痛点 + 选题意义
- 需求分析页：三种角色的需求描述 + 用例图
- 技术选型页：Spring Boot + MyBatis-Plus + MySQL + Thymeleaf，配两句话说明选型理由
- 架构设计页：系统的分层架构图 + 模块划分
- 数据库设计页：核心ER图 + 六张核心表结构
- 功能实现页：4到5张核心页面截图，每张配一句实现介绍
- 系统测试页：测试用例汇总 + 测试结论
- 总结与展望页：完成度 + 不足 + 未来扩展
PPT最重要的原则是：不要放一大段代码，老师看不完也不关心。页面截图的优先级远高于代码块。给页面截图时，不要截整个浏览器窗口，要截局部干净区域，字体太小会直接被评委吐槽。我见过一个学弟把整个屏幕带任务栏、浏览器标签栏一起截进去，投影出来字都看不清，直接被说了一顿。
6.3 演示视频的录制脚本，照着拍就能过
现在很多学校要求提交演示视频，尤其非全日制和远程答辩的场景。演示视频的黄金标准是时长5分钟，内容完整，画面流畅，关键步骤有讲解。
我建议你按一个固定脚本来录：
第一段（约30秒）：登录界面演示，展示管理员账号登录，输入用户名密码和验证码，进入系统首页，顺手提一句“系统采用Spring Security做登录认证”。
第二段（约90秒）：核心业务演示，从新增一名长者开始，填基本信息、上传头像、分配床位、绑定家属，然后在长者列表看到新记录。这段是演示的重头戏，一定要把表单填得真实一点，不要用“测试1”“123456”这种数据。
第三段（约60秒）：健康数据演示，给刚才的长者录入一条体温心率记录，然后展示健康趋势曲线；如果数据超过阈值，切到预警页面展示预警记录生成。
第四段（约60秒）：权限演示，退出登录，用家属账号登录，展示家属只能看到自己绑定的老人信息。这段对答辩帮助极大，直接证明你做了数据权限控制。
第五段（约30秒）：统计页面演示，展示首页的今日入住人数、预警数量、护理任务完成率等统计卡片，收尾。
录制软件用OBS Studio，分辨率设1920×1080，帧率30即可。录制前把你要点击的流程在纸上写一遍，照着走，避免直播式翻车。我的经验是，录三遍总能选出最好的一条，别指望一遍过。
7. 答辩现场高频问题与避坑清单
最后这部分，是项目能不能拿高分的临门一脚。我把答辩现场老师最常问的问题，以及围绕这套系统你会遇到的技术追问，一次性列清楚。
7.1 高频提问与应答思路
第一个问题：为什么选择Spring Boot而不是传统的SSM？
应答要点：Spring Boot的自动配置降低了项目搭建成本，内嵌Tomcat让部署只需要一个jar包，加上生态成熟，是目前Java Web开发的主流选择。重点要落在“提高开发效率、把精力放到业务逻辑上”这个角度。
第二个问题：JWT和Session有什么区别，你的系统为什么用JWT？
应答要点：JWT无状态，服务端不需要存储会话信息，适合分布式部署；但存在Token吊销困难的问题。如果答辩时被反问，你就说毕设规模下用JWT完全够用，还附带说明Token设置了24小时过期时间，用HTTPS加密传输。这里千万不要和老师争论“JWT比Session更好”，先承认各自的适用场景，再说明你选择的合理性。
第三个问题：权限控制是怎么实现的？
这道题是必答题，答不好直接暴露是否自己写的代码。正确的回答思路是：后端角色权限基于RBAC模型，用户表、角色表、菜单表三张表通过关联表组合权限；登录成功后，后端保存当前用户的权限标识列表，访问每个接口时通过自定义注解 + 拦截器校验是否有对应权限；数据权限上，家属只允许访问与自己绑定关系的数据，程序在Service层强制加绑定条件。
第四个问题：系统如何防止SQL注入？
应答要点：MyBatis参数占位符#{}使用的是PreparedStatement预编译，能有效防止SQL注入。如果你用了${}拼接，一定要想好怎么解释，否则就是送命题。
7.2 源码层面的“防问倒”准备
有些老师喜欢直接看代码，一边翻一边问。你需要在答辩前做一次代码自查，重点检查三处：
首先，Controller层应该保持薄，不能有业务逻辑。如果某个Controller里出现了超过20行的循环判断，或者直接调Mapper的代码，赶紧重构。老师看到你Controller里乱糟糟，第一印象直接崩塌。
其次，事务注解不能瞎加。批量导入、新增账单、退住操作这些涉及多表写入的方法，一定要加@Transactional。老师如果问“为什么要加事务”，你可以回答“保证多张表操作的一致性，如果中途某个写操作失败，整体回滚”。
第三，异常处理必须统一。不要让你的接口报错时直接把红色堆栈信息抛给用户，那样太不专业了。写一个@RestControllerAdvice全局异常处理器，对BusinessException返回友好的错误信息，对未捕获异常返回“系统繁忙”的提示，并记录日志。这段代码是答辩时的一个隐藏武器，也是你“拥有良好开发习惯”的最好证明。
说句可能的题外话，如果你拿到了一套网上流传的智慧养老平台源码，不要拿来就跑。先花一个晚上把数据库表结构和业务逻辑从头到尾跟一遍，把你讲解不了的代码换成自己能解释清楚的实现。答辩现场，老师不在乎你代码写得多优雅，只在乎你能不能答得上来。自己讲不出来的模块，要么背熟，要么干脆删掉。
我在实际辅导里见过太多反面案例了：有人项目功能做得花团锦簇，结果连“#{}和${}有什么区别”都答不上来，最后老师怀疑不是自己做的，连及格都差点没保住。毕设这个东西，“能做出来”只是底线，“能讲明白”才是拿到高分的关键。这篇实录把从选题到答辩的完整链路都给你捋清楚了，接下来就看你自己把代码跑起来、把每个流程走通了。
本文还有配套的精品资源，点击获取
