企业官网建设流程全解析

每年到了毕业设计开题季，“社区服务类”的题目几乎每个班都能碰到几个同学选中，“基于Spring Boot的社区助老志愿者服务平台”属于这类题目里的常客。我前前后后帮几位朋友和读者梳理过这个方向，发现很多人一开始都以为它不过是一套增删改查，真动手之后才反应过来：这个题目的难点根本不在代码，而在需求本身——老人、志愿者、社区管理员这三类人，各自在这套系统里想要的完全是三样东西。

这篇文章就围绕这个题目，从需求拆解、技术选型、数据库设计、核心业务实现，到实测踩坑和答辩准备，完整过一遍。无论你是刚开题还没定方案的，还是已经写了一半代码被各种细节卡住的，应该都能从这里找到可以参考的答案。

1. 选题拆解：社区助老平台到底在解决什么问题

很多同学选这个题，是因为“助老”主题好写背景、正能量，但真要列出功能清单时容易陷入两种极端：要么只做了个志愿者活动管理后台，老人端完全没体现；要么功能铺得很开，活动、捐赠、健康档案、心理咨询、课程报名全往里塞，最后哪个都没做深。先把需求捋清楚，后面所有设计才有依据。

1.1 三类使用者的真实诉求

社区助老服务这件事，在没系统之前是怎么运转的？社区工作人员拿一个Excel登记独居老人的基本信息，有服务需求就打几个电话问有没有愿意接的志愿者，或者在一个微信群里发公告接龙。志愿者报名靠手速，服务时长靠手写签字，月底统计时长的时候翻登记本、对聊天记录，误差很大。

把这些问题翻译成系统需求，就能看到三类使用者的核心诉求完全不同：

• 老人（或者老人的家属）要的是“约得上、看得见”。他们需要低门槛地发布需求、查看服务安排、看到谁来服务、服务完之后留个评价或反馈。
• 志愿者要的是“找得到、算得清”。他们关注有哪些活动、时间地点是否合适、报名是否成功、累计服务了多少时长。这个时长在很多地方和评优、补贴挂钩，所以精确性很重要。
• 社区管理员要的是“控得住、查得到”。他要审核志愿者身份、审核活动报名、确认服务时长、处理投诉和反馈，还要能在月度汇报时拿出“这个月服务了多少人次、累计多少小时”这种数据。

这三类诉求如果只做一个角色能用的后台，题目就废了一半。好的设计应当让三类人都有自己的入口和视图。

1.2 从痛点推导功能需求矩阵

把上一节的需求翻译成功能点，大致是这么一张表：

这里有个容易被忽略的点：老人端不是每个老人都会用智能手机，实际操作里往往是子女代注册、社区工作人员代操作。所以老人端的设计要考虑“代办”场景，字段里要预留紧急联系人、家属手机号这种信息，而不是只做给老人自己用。

1.3 范围收敛：一条主线加三个辅助模块

毕业设计最忌讳的就是贪多。我给这个题目的定位很明确：一条主线加三个辅助模块。

主线是“活动型志愿服务闭环”：管理员发布志愿活动 → 志愿者浏览并报名 → 管理员审核报名 → 活动执行时确认签到和服务时间 → 后台生成服务记录 → 审核通过后累计志愿时长。这条链路覆盖了平台最核心的价值，也是答辩时最能讲清楚的东西。

辅助模块围绕主线展开：老人端的需求留言（管理员看到留言后可以转化为一场线下活动）、系统公告与站内通知、数据统计面板。至于即时聊天、在线支付、GIS地图找活动这类东西，除非是个人能力很强想加亮点，否则不建议碰。每多一个模块，就意味着多一份联调、测试和Bug修复成本，毕业设计的时间经不起这么消耗。

2. 技术栈取舍：为什么最终选了 Spring Boot + Thymeleaf + MyBatis-Plus 这一套

技术选型是开题报告里最先要写的部分，也是最容易被答辩老师问“为什么不用XX”的部分。选型没有绝对的对错，关键是你能不能说清楚取舍的理由。

2.1 为什么是 Spring Boot 而不是 SSM 或二开框架

如果是五年前，这个题目可能得用 SSM（Spring + 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。继承BaseMapper<T>之后，selectById、insert、updateById、deleteById全都有了，能省掉大量无意义的样板代码。

第二，条件构造器适合动态查询。比如活动列表要按标题模糊查询、按状态筛选、按时间排序，用LambdaQueryWrapper几行就能写出来，不用在 XML 里拼<if>标签。

第三，分页插件和逻辑删除开箱即用。分页查询在管理端列表页是标配，配置一个MybatisPlusInterceptor就可以Page<T>分页。逻辑删除在毕设里可以用来做“软删除”，也方便在论文里讲数据保留的意义。

顺带一提，JDK 版本建议用 8 或 11，Spring Boot 用 2.7.x。不要为了追新用 Spring Boot 3.x + JDK 17，虽然也能做，但网上资料、依赖兼容性、答辩时老师的熟悉程度，都不如 2.7 这根“老黄瓜”稳。

3. 数据库与状态流设计：整个项目里最烧脑的部分

数据库设计决定了后面所有代码怎么写。表结构设计得合理，业务代码顺理成章；表设计得别扭，后面每个查询都在跟它做斗争。我建议先想清楚表关系，再动手写实体类。

3.1 八张核心表的关系拓扑

围绕前面说的主线，核心表我规划为八张：

这里有一个设计决策值得展开说：为什么不在 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 + 拦截器 + 自定义注解就足够，而且更能展示你“理解鉴权原理”。

思路是：

1. 登录成功后，用用户的 id 和角色生成一个 JWT Token 返回前端；
2. 前端每次请求在 Header 里带Authorization: Bearer <token>；
3. 后端写一个拦截器，在进入 Controller 之前解析 Token，把用户信息放进 ThreadLocal；
4. 通过自定义注解@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 id="incrSignedCount"> 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 LambdaQueryWrapper<ActivitySignup>() .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 type="datetime-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 Converter<String, 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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

5.2 逻辑删除字段与唯一索引冲突

这是个隐蔽的坑。你的用户表给username设置了唯一索引，同时用了 MyBatis-Plus 的逻辑删除（deleted字段，0 存在 1 删除）。当用户注销账号时执行删除，其实是把deleted置为 1。这时候如果新用户想注册同一个用户名，会因为唯一索引冲突报 “Duplicate entry”。

为什么？因为唯一索引管的是整行数据的字段组合，(username='zhangsan', deleted=0)和(username='zhangsan', deleted=1)已经是两行不冲突的数据了，但你的唯一索引只落在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.active=prod切换。
• 8080 端口被占用。服务器上可能有其他进程占了 8080，用nohup java -jar xxx.jar --server.port=8081 &换一个端口启动，或者先把占用进程清掉。
• 静态资源加载不出来。用了 Thymeleaf 的话，页面模板必须放在src/main/resources/templates下，静态文件放src/main/resources/static下。如果还是找不到，检查是否配置了spring.mvc.static-path-pattern或server.servlet.context-path，context-path 一旦配置，所有请求路径都会带前缀，页面里的资源路径也要跟着调整。

5.5 前端校验与后端校验脱节

这是个容易被扣分但不报错的问题。典型场景：活动报名截止时间在前端写了一个disabled判断，但后端接口没有校验，导致用户通过工具直接调接口也能在截止后报名成功。

正确做法是：前端校验是为了用户体验，后端校验才是安全底线。凡是涉及状态变更的接口，后端都必须重新校验业务规则，不要相信任何前端传来的数据。这个观念不仅能在答辩时体现你的工程素养，也是毕业设计代码里很少见的亮点。

6. 答辩与文档准备：用一条业务演示链路证明工作量

代码写完只是第一步，毕业设计最终要过的是论文和答辩两关。这个项目的优势在于“业务闭环清楚”，但你需要在答辩时把这一点完整地展示出来，而不是对着 PPT 念功能列表。

6.1 十分钟演示脚本：从建活动到看到排行榜变化

我建议的演示路线是这样一条完整链路：

1. 用管理员账号登录，进入管理端，新建一场“周末独居老人探访”活动，设置招募 3 人，报名截止时间为两天后；
2. 切换到志愿者账号登录，在活动列表里找到这场活动，点击报名；
3. 回到管理员账号，在报名审核列表里看到这条待审核记录，审核通过；
4. 再切到管理员的“服务记录”页面，为刚才这位志愿者录入服务开始和结束时间，生成一条待审核服务记录；
5. 审核通过这条服务记录；
6. 打开志愿者个人主页，看到累计时长已经增加了刚才录入的分钟数；
7. 打开管理端统计首页，看到志愿者总人数、本月活动数、累计服务时长等数字发生变化；
8. 最后切到老人账号登录，查看这条服务记录以及对服务的反馈留言功能。

这整条链路大概需要 10 分钟。它的好处在于：每个演示步骤背后都对应着数据库里的一条新增记录，你在视频里、PPT 里、答辩现场能清晰回答“这一步操作背后发生了什么”。如果只是零散地展示“活动管理页面长什么样”，说服力会弱很多。

6.2 论文结构怎么安排最稳妥

毕设论文的结构大体是固定的，但这个题目的重心应该放在“需求分析”和“数据库设计”上。因为系统本身不是纯算法类，业务逻辑的复杂度更多体现在角色关系和状态流转上。

我建议的章节重点：

论文里给每个模块配一张截图，配上 4-5 行文字说明做了什么、怎么做的。不要贴大段完整源码，一方面查重会很受影响，另一方面答辩老师也不会因为你贴得全就给高分，他更看你有没有真正理解自己写的东西。

6.3 答辩高频追问与应答思路

整理几个这个题目几乎必问的问题，提前想好答案：

1. “JWT 和传统 Session 有什么区别，为什么选 JWT？”——可以答：JWT 无状态、服务端不需要存会话信息、适合前后端分离和扩展；Session 需要服务端存储、依赖 Cookie。本科毕设答到这个层面就够了。
2. “逻辑删除和物理删除你怎么选？”——可以答：涉及到用户、服务记录这类需要留存审计数据的场景，逻辑删除更安全；纯日志或临时表可以物理删除。
3. “报名时并发怎么处理？”——把 4.2 节的乐观扣减思路讲一遍，顺便说出“用受影响行数判断是否成功”这个关键点。
4. “服务时长为什么存冗余字段？”——因为列表页和个人主页高频读取汇总数据，实时 SUM 性能差；冗余字段和明细的一致性通过事务保证。
5. “你的权限控制是怎么做的？”——JWT 拦截器 + 自定义注解，讲清楚校验流程即可，不要说用了 Spring Security 却答不上细节。

如果这些问题你都能张口就来，答辩基本上不会出问题。

这个题目前前后后我帮人捋过好几遍，最深的体会是：它的难点从来不在某个框架的技巧上，而在你把一条“从活动发布到时长累计”的业务链条想得有多透。如果你准备动手，先把这条闭环在纸上画出来，画出角色、画出状态、画出每一步的数据变化。画得通，代码自然写得顺。最后再做页面的时候，记得老人端的字号别低于 16px，按钮间距尽量大一点——这套系统最终服务的是真实的人，这个细节比任何技术点都重要。