每年到了毕业设计开题季“社区服务类”的题目几乎每个班都能碰到几个同学选中“基于Spring Boot的社区助老志愿者服务平台”属于这类题目里的常客。我前前后后帮几位朋友和读者梳理过这个方向发现很多人一开始都以为它不过是一套增删改查真动手之后才反应过来这个题目的难点根本不在代码而在需求本身——老人、志愿者、社区管理员这三类人各自在这套系统里想要的完全是三样东西。这篇文章就围绕这个题目从需求拆解、技术选型、数据库设计、核心业务实现到实测踩坑和答辩准备完整过一遍。无论你是刚开题还没定方案的还是已经写了一半代码被各种细节卡住的应该都能从这里找到可以参考的答案。1. 选题拆解社区助老平台到底在解决什么问题很多同学选这个题是因为“助老”主题好写背景、正能量但真要列出功能清单时容易陷入两种极端要么只做了个志愿者活动管理后台老人端完全没体现要么功能铺得很开活动、捐赠、健康档案、心理咨询、课程报名全往里塞最后哪个都没做深。先把需求捋清楚后面所有设计才有依据。1.1 三类使用者的真实诉求社区助老服务这件事在没系统之前是怎么运转的社区工作人员拿一个Excel登记独居老人的基本信息有服务需求就打几个电话问有没有愿意接的志愿者或者在一个微信群里发公告接龙。志愿者报名靠手速服务时长靠手写签字月底统计时长的时候翻登记本、对聊天记录误差很大。把这些问题翻译成系统需求就能看到三类使用者的核心诉求完全不同老人或者老人的家属要的是“约得上、看得见”。他们需要低门槛地发布需求、查看服务安排、看到谁来服务、服务完之后留个评价或反馈。志愿者要的是“找得到、算得清”。他们关注有哪些活动、时间地点是否合适、报名是否成功、累计服务了多少时长。这个时长在很多地方和评优、补贴挂钩所以精确性很重要。社区管理员要的是“控得住、查得到”。他要审核志愿者身份、审核活动报名、确认服务时长、处理投诉和反馈还要能在月度汇报时拿出“这个月服务了多少人次、累计多少小时”这种数据。这三类诉求如果只做一个角色能用的后台题目就废了一半。好的设计应当让三类人都有自己的入口和视图。1.2 从痛点推导功能需求矩阵把上一节的需求翻译成功能点大致是这么一张表使用者核心诉求对应的功能模块老人/家属约得上、看得见活动浏览与一键咨询、服务需求留言、服务记录查询、反馈评价志愿者找得到、算得清活动报名、我的报名记录、服务时长明细、累计时长排行管理员控得住、查得到志愿者入驻审核、活动发布与管理、报名审核、时长审核、公告发布、统计面板这里有个容易被忽略的点老人端不是每个老人都会用智能手机实际操作里往往是子女代注册、社区工作人员代操作。所以老人端的设计要考虑“代办”场景字段里要预留紧急联系人、家属手机号这种信息而不是只做给老人自己用。1.3 范围收敛一条主线加三个辅助模块毕业设计最忌讳的就是贪多。我给这个题目的定位很明确一条主线加三个辅助模块。主线是“活动型志愿服务闭环”管理员发布志愿活动 → 志愿者浏览并报名 → 管理员审核报名 → 活动执行时确认签到和服务时间 → 后台生成服务记录 → 审核通过后累计志愿时长。这条链路覆盖了平台最核心的价值也是答辩时最能讲清楚的东西。辅助模块围绕主线展开老人端的需求留言管理员看到留言后可以转化为一场线下活动、系统公告与站内通知、数据统计面板。至于即时聊天、在线支付、GIS地图找活动这类东西除非是个人能力很强想加亮点否则不建议碰。每多一个模块就意味着多一份联调、测试和Bug修复成本毕业设计的时间经不起这么消耗。2. 技术栈取舍为什么最终选了 Spring Boot Thymeleaf MyBatis-Plus 这一套技术选型是开题报告里最先要写的部分也是最容易被答辩老师问“为什么不用XX”的部分。选型没有绝对的对错关键是你能不能说清楚取舍的理由。2.1 为什么是 Spring Boot 而不是 SSM 或二开框架如果是五年前这个题目可能得用 SSMSpring Spring MVC MyBatis手写配置。现在直接用 Spring Boot原因很简单约定优于配置内嵌Tomcat一个mvn spring-boot:run就能把项目拉起来省下的时间可以用来打磨业务逻辑。有同学问过为什么不直接拿一些现成的开源后台管理系统二次开发。我的看法是毕设查重和答辩这两关过不过得去先不说光是你对代码的熟悉程度就是个问题。二开框架里带着大量你根本没读过的基础代码答辩老师随便挑一个点问“这个角色权限是怎么实现的”你就容易答不上来。从零基于 Spring Boot 写一套哪怕逻辑朴素一点也是自己的东西讲起来踏实。2.2 前后端分离的诱惑与毕业设计的现实现在前端 Vue 很流行很多同学觉得不上 Vue 就显得技术落后。但我想说对于“社区助老志愿者服务平台”这种以表单和列表为主的管理型系统前后端分离带来的好处远没有付出的成本多。前后端不分离服务端渲染用 Thymeleaf Bootstrap页面模板直接在服务端渲染好返回。好处有三个不需要处理跨域问题不需要纠结 Token 存在 localStorage 还是 cookie 里演示的时候一个应用跑起来页面直接访问不会出现前端起一个端口、后端起一个端口、联调时哪边漏配的尴尬Spring Boot 对 Thymeleaf 的支持非常成熟模板里可以直接用th:each遍历列表、用th:if做条件判断写起来很像后端顺手写页面对后端同学非常友好。反过来如果你确实想展示前后端分离能力且已经能熟练写 Vue 和 Ribbon 层面的联调那另说。但作为稳妥方案Thymeleaf 依然是我给大多数人的推荐。2.3 持久层选 MyBatis-Plus 的三个理由持久层我推荐 MyBatis-Plus理由有三个。第一单表 CRUD 几乎不用写 SQL。继承BaseMapperT之后selectById、insert、updateById、deleteById全都有了能省掉大量无意义的样板代码。第二条件构造器适合动态查询。比如活动列表要按标题模糊查询、按状态筛选、按时间排序用LambdaQueryWrapper几行就能写出来不用在 XML 里拼if标签。第三分页插件和逻辑删除开箱即用。分页查询在管理端列表页是标配配置一个MybatisPlusInterceptor就可以PageT分页。逻辑删除在毕设里可以用来做“软删除”也方便在论文里讲数据保留的意义。顺带一提JDK 版本建议用 8 或 11Spring Boot 用 2.7.x。不要为了追新用 Spring Boot 3.x JDK 17虽然也能做但网上资料、依赖兼容性、答辩时老师的熟悉程度都不如 2.7 这根“老黄瓜”稳。3. 数据库与状态流设计整个项目里最烧脑的部分数据库设计决定了后面所有代码怎么写。表结构设计得合理业务代码顺理成章表设计得别扭后面每个查询都在跟它做斗争。我建议先想清楚表关系再动手写实体类。3.1 八张核心表的关系拓扑围绕前面说的主线核心表我规划为八张表名作用关键关联t_user登录账号所有角色的公共信息主键被 t_volunteer、t_elder 引用t_volunteer志愿者扩展档案user_id 一对一关联 t_usert_elder老人档案可代办user_id 一对一关联 t_usert_activity志愿活动主表与 t_activity_signup 一对多t_activity_signup活动报名记录activity_id、volunteer_idt_service_record服务记录时长结算的依据activity_id、volunteer_id、elder_idt_feedback老人需求留言与反馈elder_id、auditor_idt_notice系统公告publisher_id这里有一个设计决策值得展开说为什么不在 t_user 表里直接加志愿者和老人的字段而要拆成扩展表因为志愿者注册需要填的技能标签、审核状态和老人档案需要的健康情况、紧急联系人完全是两类信息。把它们塞进一张表字段会非常凌乱空值也很多。拆开后t_user 只负责登录这件事t_volunteer 和 t_elder 专注于各自的业务扩展。这也符合数据库设计的“职责单一”思路。3.2 关键表字段设计从 t_activity 看设计取舍活动表是整个系统的核心。直接看建表语句CREATE TABLE t_activity ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, title VARCHAR(100) NOT NULL COMMENT 活动标题, content TEXT COMMENT 活动描述, category VARCHAR(20) DEFAULT 其他 COMMENT 活动分类, location VARCHAR(255) COMMENT 活动地点, start_time DATETIME NOT NULL COMMENT 活动开始时间, end_time DATETIME NOT NULL COMMENT 活动结束时间, recruit_end_time DATETIME NOT NULL COMMENT 报名截止时间, need_count INT NOT NULL DEFAULT 1 COMMENT 招募人数, signed_count INT NOT NULL DEFAULT 0 COMMENT 已报名人数, status TINYINT NOT NULL DEFAULT 0 COMMENT 0招募中 1进行中 2已结束 3已取消, publisher_id BIGINT NOT NULL COMMENT 发布人ID, deleted TINYINT DEFAULT 0 COMMENT 逻辑删除 0存在 1删除, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, KEY idx_status_time (status, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT志愿活动表;几个容易忽略的设计点need_count和signed_count为什么要单独两个字段而不是每次count报名表因为活动列表页要展示“已报名/总名额”如果每次都实时统计列表一多就要关联分组查询。用冗余字段记录报名人数在报名成功时加一列表查询就快很多。这个冗余是值得的因为系统是“读多写少”的场景。status用 TINYINT 不用字符串。一是省空间二是方便比较和索引三是在代码里用常量或枚举去映射语义一样清晰。时间都推荐用DATETIME而非TIMESTAMP。TIMESTAMP有时区转换问题2038年还有上限毕设系统虽然没那么多数据但养成好习惯总没错。加了一个idx_status_time联合索引是为了支撑列表页“按状态 时间排序”的常用查询。3.3 状态机设计活动、报名、服务记录如何联动这是个很容易被做成一盘散沙的地方。活动有状态报名有状态服务记录也有状态三者如果不联动就会出现“活动已经结束了志愿者还在报名”这种明显 Bug。活动状态0招募中 → 1进行中 → 2已结束另加 -1已取消这里为了简单用 1/2/3 也可以看自己习惯但别混着用。报名的前提条件是活动状态为“招募中”且当前时间早于recruit_end_time。活动开始后就应禁止报名。报名状态0待审核 → 1已通过 → 2已拒绝 → 3已完成 → 4已取消。注意 3 和 4 的区别3 是指报名通过后志愿者真实参与了服务并完成了时长确认4 是指审核通过后志愿者因故没来或者用户在审核前主动取消。这两种情况对数据统计意义完全不同。服务记录状态0待审核 → 1已通过 → 2已驳回。只有报名状态为“已通过”的志愿者才允许生成服务记录服务记录审核通过后志愿时长才累计到志愿者档案上。这个联动关系必须在编码前画清楚否则后面写业务逻辑时很容易漏掉某个状态组合。3.4 服务时长的存储模型冗余与一致性的平衡服务时长的计量单位我强烈建议在数据库里统一按“分钟”存整数避免用浮点的小时导致精度问题。比如服务了 90 分钟就存90页面展示时再转成“1小时30分钟”。这里涉及一个经典问题志愿者累计时长是每次查询时实时SUM还是在一个冗余字段里累计我的选择是t_service_record存明细时长t_volunteer表加一个total_minutes冗余字段做累计。每次服务记录审核通过后在同一事务里把时长加到志愿者的累计字段中。好处是志愿者个人主页、排行榜这类高频查询不需要实时聚合明细表性能好SQL 也好写。代价是一致性维护如果审核被驳回、记录被删除累计字段也得相应回退。所以在写 Service 层时必须把所有会改变服务记录状态的操作都纳入事务管理并画一条“只有审核通过才累加只有审核回退才扣减”的规则。4. 核心业务代码落地登录鉴权、报名防超售、时长结算闭环框架搭好、表建好之后真正的核心代码集中在几条业务链路上。这里挑几个值得写进论文、也值得在答辩时打开 IDE 展示的实现细节。4.1 登录鉴权避免引入 Spring Security 的笨重方案很多毕设题目的交流群里常看到有人问是不是要用 Spring Security我的意见是这个系统的规模完全没有必要上 Spring Security用 JWT 拦截器 自定义注解就足够而且更能展示你“理解鉴权原理”。思路是登录成功后用用户的 id 和角色生成一个 JWT Token 返回前端前端每次请求在 Header 里带Authorization: Bearer token后端写一个拦截器在进入 Controller 之前解析 Token把用户信息放进 ThreadLocal通过自定义注解RequireRole标记哪些接口需要哪种角色。核心拦截器逻辑大致长这样Component public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 非 Controller 方法直接放行例如静态资源 if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod (HandlerMethod) handler; // 登录接口放行 if (handlerMethod.hasMethodAnnotation(AllowAnonymous.class)) { return true; } // 提取 Token String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析 Token得到用户ID和角色 LoginUser loginUser JwtUtil.parseToken(token.substring(7)); if (loginUser null) { throw new BusinessException(401, 无效的登录凭证); } // 方法级角色校验 RequireRole requireRole handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole ! null) { String[] roles requireRole.value(); if (!Arrays.asList(roles).contains(loginUser.getRole())) { throw new BusinessException(403, 没有权限执行此操作); } } // 写入线程上下文 UserContext.set(loginUser); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.remove(); } }这里有一个特别容易被忽略的细节afterCompletion里必须调用UserContext.remove()。ThreadLocal 如果在请求结束后不清理在高并发下会造成用户信息串号甚至内存泄漏。这一点写进论文里老师会觉得你真的考虑过并发场景下的资源释放问题。4.2 活动报名与并发防超售活动报名表面上就是一个insert但嵌着一个非常经典的并发问题最后一个名额被两个人同时抢到怎么办你不能在代码里先select一下signed_count need_count再update名额因为两个请求同时读到剩余 1 个名额都会认为还能报名结果报名记录插了两条名额变成负数。解决方案是“乐观扣减”把名额判断和更新放在同一条 SQL 里用受影响行数判断是否成功。update idincrSignedCount UPDATE t_activity SET signed_count signed_count 1 WHERE id #{activityId} AND signed_count lt; #{needCount} /update配合事务的业务代码Transactional(rollbackFor Exception.class) public Long signUp(Long activityId, Long volunteerId) { Activity activity activityMapper.selectById(activityId); if (activity null || activity.getStatus() ! ActivityStatus.RECRUITING) { throw new BusinessException(活动不存在或不在报名期); } if (activity.getRecruitEndTime().isBefore(LocalDateTime.now())) { throw new BusinessException(报名已截止); } // 判重一个人不能重复报名同一个活动 Long count signupMapper.selectCount(new LambdaQueryWrapperActivitySignup() .eq(ActivitySignup::getActivityId, activityId) .eq(ActivitySignup::getVolunteerId, volunteerId) .in(ActivitySignup::getStatus, SignupStatus.PENDING, SignupStatus.PASS)); if (count 0) { throw new BusinessException(您已报名过该活动请勿重复操作); } // 核心原子扣减名额受影响行数为0说明名额已满 int updated activityMapper.incrSignedCount(activityId, activity.getNeedCount()); if (updated 0) { throw new BusinessException(该活动名额已满); } // 插入报名记录 ActivitySignup signup new ActivitySignup(); signup.setActivityId(activityId); signup.setVolunteerId(volunteerId); signup.setStatus(SignupStatus.PENDING); signupMapper.insert(signup); return signup.getId(); }这里再解释一下为什么不用悲观锁SELECT FOR UPDATE悲观锁虽然也能解决但它要求事务期间一直持有行锁并发性能差而且在分布式场景下还容易死锁。对一个报名场景来说乐观锁的体验更好代码也更简单。你真能在答辩时把这个“为什么选乐观锁而不是悲观锁”讲明白这一分基本就拿到了。4.3 服务时长录入与审核回写服务记录是“时长闭环”的最后一环。管理员的操作为选择某场活动下的某个已通过报名志愿者填写实际服务开始时间、结束时间系统自动计算分钟数生成待审核记录。审核通过时把分钟数回写到志愿者累计时长里。计算分钟数的代码public Integer calcMinutes(LocalDateTime startTime, LocalDateTime endTime) { if (endTime.isBefore(startTime)) { throw new BusinessException(服务结束时间不能早于开始时间); } return (int) Duration.between(startTime, endTime).toMinutes(); }审核通过的回写逻辑Transactional(rollbackFor Exception.class) public void approveServiceRecord(Long recordId, Long auditorId) { ServiceRecord record serviceRecordMapper.selectById(recordId); if (record null || record.getStatus() ! ServiceStatus.PENDING) { throw new BusinessException(记录不存在或已被处理); } record.setStatus(ServiceStatus.APPROVED); record.setAuditorId(auditorId); record.setAuditTime(LocalDateTime.now()); serviceRecordMapper.updateById(record); // 回写志愿者累计时长 volunteerMapper.addTotalMinutes(record.getVolunteerId(), record.getDurationMinutes()); }回写用的同样是原子更新不要“先查再改”直接UPDATE t_volunteer SET total_minutes total_minutes #{minutes} WHERE id #{volunteerId}这个设计可以拿出来强调“冗余字段的一致性维护”所有修改服务记录状态的操作都必须走 Service 层这些带事务的方法不允许直接改数据库表。4.4 首页统计面板与排行查询管理端首页通常要展示几个统计数字志愿者总数、本月活动数、累计服务时长、服务人次。这些数据虽然网上到处是教程但最好用一条能体现 SQL 聚合能力的查询来支撑“技术亮点”。比如“本月服务时长排行榜”SELECT v.real_name, COUNT(r.id) AS service_count, SUM(r.duration_minutes) AS total_minutes FROM t_service_record r JOIN t_volunteer v ON r.volunteer_id v.id WHERE r.status 1 AND r.service_date DATE_FORMAT(CURRENT_DATE, %Y-%m-01) GROUP BY r.volunteer_id, v.real_name ORDER BY total_minutes DESC LIMIT 10;注意WHERE r.status 1这个条件只统计审核通过的服务记录。如果漏了它排行榜会把待审核甚至被驳回的记录都算进去这在业务上是不合理的。很多同学实现排行时只想着 SQL 怎么写忽略了“数据可信度”这道坎答辩时如果被问到会很被动。5. 实测踩坑记录五个最容易让毕设翻车的细节这个题目我做下来遇到的大部分问题不在业务复杂度而在一些“看着很小但是能卡你一整天”的细节。挑五个最典型的记录在这里。5.1 时间格式处理的连环坑第一个坑前端传日期字符串给后端LocalDateTime直接报错。前端input typedatetime-local传的值是2025-05-20T14:30这种带T的格式而后端实体类字段用DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)去接格式对不上Spring 就会报类型转换失败。解决办法有两种。第一种是每个字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)但只对 JSON 请求体有效。第二种更彻底注册一个全局转换器Component public class StringToLocalDateTimeConverter implements ConverterString, LocalDateTime { private static final DateTimeFormatter FORMATTER DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); Override public LocalDateTime convert(String source) { if (source null || source.trim().isEmpty()) { return null; } // 兼容输入框传过来的 2025-05-20T14:30 String value source.trim().replace(T, ); if (value.length() 16) { value :00; } return LocalDateTime.parse(value, FORMATTER); } }然后在WebMvcConfigurer里注册。这类“全局统一日期格式”的操作在项目里定好一个约定会让后面的开发顺畅很多。第二个坑是 MySQL 时区差 8 小时。明明数据库里存的是下午两点页面显示变成凌晨两点。原因很可能是连接串没有配置时区。MySQL 8.0 建议连接串写成jdbc:mysql://localhost:3306/community_volunteer?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse5.2 逻辑删除字段与唯一索引冲突这是个隐蔽的坑。你的用户表给username设置了唯一索引同时用了 MyBatis-Plus 的逻辑删除deleted字段0 存在 1 删除。当用户注销账号时执行删除其实是把deleted置为 1。这时候如果新用户想注册同一个用户名会因为唯一索引冲突报 “Duplicate entry”。为什么因为唯一索引管的是整行数据的字段组合(usernamezhangsan, deleted0)和(usernamezhangsan, deleted1)已经是两行不冲突的数据了但你的唯一索引只落在username上所以被挡住了。解决方案有三种取消username唯一索引注册时用selectCount判断是否已存在。逻辑删除状态下视为“用户名已占用”不允许重新注册。唯一索引改成(username, deleted)联合索引。但是注意如果只用 0/1 两个值删除两个同名用户后第三个还是会被挡。更稳的做法是把逻辑删除字段的删除值改成主键 id比如删除时deleted id这样联合索引的每条删除记录在deleted列上都不相同永远不会冲突。对毕设系统而言方案一最简单可靠。不要小看这个场景很多人做用户注销或者账号删除功能时才暴露出来离答辩就差几天心态很容易崩。5.3 并发报名导致名额超售前面已经讲了乐观扣减的写法这里说的是另一个问题很多同学写完报名功能后只会手动测一遍根本不会主动去验证并发情况下会不会出 Bug。真正到压力测试时才发现超售就慌了。我测试时常用一个简单的并发模拟用CountDownLatch和线程池同时发起 50 个报名请求活动名额只设 5 个。跑完之后查报名表数量如果大于 5就说明并发保护没生效。复制这里的代码到你的测试类里跑一遍ExecutorService pool Executors.newFixedThreadPool(20); CountDownLatch ready new CountDownLatch(20); CountDownLatch start new CountDownLatch(1); for (int i 0; i 20; i) { long volunteerId i 1; pool.submit(() - { ready.countDown(); try { start.await(); signupService.signUp(1L, volunteerId); } catch (Exception e) { // 名额已满或重复报名等业务异常记录即可 } }); } ready.await(); start.countDown(); pool.shutdown();跑完之后查一下库里报名数量。这个测试本身就可以写进你的测试章节属于“并发控制验证”的重要论据。5.4 服务器部署后的环境差异问题本地 Windows 上跑得飞起打包上传到 Linux 服务器上就各种问题。这类问题通常集中在三处数据库地址还写着localhost服务器上应用连的是服务器自己的本地库如果数据库不在同一台机器上就会连不上。应该把配置拆成application-dev.yml和application-prod.yml部署时用--spring.profiles.activeprod切换。8080 端口被占用。服务器上可能有其他进程占了 8080用nohup java -jar xxx.jar --server.port8081 换一个端口启动或者先把占用进程清掉。静态资源加载不出来。用了 Thymeleaf 的话页面模板必须放在src/main/resources/templates下静态文件放src/main/resources/static下。如果还是找不到检查是否配置了spring.mvc.static-path-pattern或server.servlet.context-pathcontext-path 一旦配置所有请求路径都会带前缀页面里的资源路径也要跟着调整。5.5 前端校验与后端校验脱节这是个容易被扣分但不报错的问题。典型场景活动报名截止时间在前端写了一个disabled判断但后端接口没有校验导致用户通过工具直接调接口也能在截止后报名成功。正确做法是前端校验是为了用户体验后端校验才是安全底线。凡是涉及状态变更的接口后端都必须重新校验业务规则不要相信任何前端传来的数据。这个观念不仅能在答辩时体现你的工程素养也是毕业设计代码里很少见的亮点。6. 答辩与文档准备用一条业务演示链路证明工作量代码写完只是第一步毕业设计最终要过的是论文和答辩两关。这个项目的优势在于“业务闭环清楚”但你需要在答辩时把这一点完整地展示出来而不是对着 PPT 念功能列表。6.1 十分钟演示脚本从建活动到看到排行榜变化我建议的演示路线是这样一条完整链路用管理员账号登录进入管理端新建一场“周末独居老人探访”活动设置招募 3 人报名截止时间为两天后切换到志愿者账号登录在活动列表里找到这场活动点击报名回到管理员账号在报名审核列表里看到这条待审核记录审核通过再切到管理员的“服务记录”页面为刚才这位志愿者录入服务开始和结束时间生成一条待审核服务记录审核通过这条服务记录打开志愿者个人主页看到累计时长已经增加了刚才录入的分钟数打开管理端统计首页看到志愿者总人数、本月活动数、累计服务时长等数字发生变化最后切到老人账号登录查看这条服务记录以及对服务的反馈留言功能。这整条链路大概需要 10 分钟。它的好处在于每个演示步骤背后都对应着数据库里的一条新增记录你在视频里、PPT 里、答辩现场能清晰回答“这一步操作背后发生了什么”。如果只是零散地展示“活动管理页面长什么样”说服力会弱很多。6.2 论文结构怎么安排最稳妥毕设论文的结构大体是固定的但这个题目的重心应该放在“需求分析”和“数据库设计”上。因为系统本身不是纯算法类业务逻辑的复杂度更多体现在角色关系和状态流转上。我建议的章节重点章节写作重点注意事项绪论社区助老背景、国内外现状不要写成长篇大论两三页引入即可需求分析三类用户用例图、业务流程图、功能需求与非功能需求这里建议把“活动型志愿服务闭环”画成流程图系统设计整体架构、模块划分、数据库 ER 图、表结构说明数据库设计是重头字段设计原因要写系统实现按模块展示关键代码和截图截图要清晰代码只放核心不要整篇贴系统测试测试环境、功能测试用例表、部分性能验证并发报名测试写在这里是加分项论文里给每个模块配一张截图配上 4-5 行文字说明做了什么、怎么做的。不要贴大段完整源码一方面查重会很受影响另一方面答辩老师也不会因为你贴得全就给高分他更看你有没有真正理解自己写的东西。6.3 答辩高频追问与应答思路整理几个这个题目几乎必问的问题提前想好答案“JWT 和传统 Session 有什么区别为什么选 JWT”——可以答JWT 无状态、服务端不需要存会话信息、适合前后端分离和扩展Session 需要服务端存储、依赖 Cookie。本科毕设答到这个层面就够了。“逻辑删除和物理删除你怎么选”——可以答涉及到用户、服务记录这类需要留存审计数据的场景逻辑删除更安全纯日志或临时表可以物理删除。“报名时并发怎么处理”——把 4.2 节的乐观扣减思路讲一遍顺便说出“用受影响行数判断是否成功”这个关键点。“服务时长为什么存冗余字段”——因为列表页和个人主页高频读取汇总数据实时 SUM 性能差冗余字段和明细的一致性通过事务保证。“你的权限控制是怎么做的”——JWT 拦截器 自定义注解讲清楚校验流程即可不要说用了 Spring Security 却答不上细节。如果这些问题你都能张口就来答辩基本上不会出问题。这个题目前前后后我帮人捋过好几遍最深的体会是它的难点从来不在某个框架的技巧上而在你把一条“从活动发布到时长累计”的业务链条想得有多透。如果你准备动手先把这条闭环在纸上画出来画出角色、画出状态、画出每一步的数据变化。画得通代码自然写得顺。最后再做页面的时候记得老人端的字号别低于 16px按钮间距尽量大一点——这套系统最终服务的是真实的人这个细节比任何技术点都重要。