清浅池塘又到一年毕设季，每年这个时候后台总能收到一堆关于选题的留言：要技术栈主流、要业务场景清晰、要好答辩、还得代码量达标不太难。今天就把我在毕业设计阶段完整做下来的一个项目——基于SpringBoot的马拉松志愿者管理系统——拿出来拆开讲一遍。这个项目从选题、架构设计、核心代码到部署调优，全流程我都走过一遍，踩过的坑也不少。如果你正在纠结计算机毕业设计选题，或者想找一个骨架干净、能扩展、好讲清楚的项目参考，那这篇内容应该能给你省下不少时间。
这个系统解决的其实是一个很真实的问题：马拉松赛事动辄几千名志愿者，岗位分配、签到统计、服务时长记录、物资发放，靠Excel和微信群根本撑不住。系统把这些流程从线下搬到线上，让赛事组织者能实时掌握志愿者动态，志愿者也能自助完成注册、报名和证书查看。因为整体业务链路完整，又用到了SpringBoot、MySQL、Redis、Vue这一套主流技术栈，作为毕业设计来说，覆盖面和技术含量都拿得出手。
需要说明一下，以下所有代码片段和配置都以我的实际工程为准，数据库表结构、接口字段、页面交互均是可运行的完整方案，你拿到后可以直接参照搭建，也可以根据自己的赛事场景做调整。我习惯把这类毕设项目当作一个小型真实系统来做，而不是“为了毕业而毕业”——这样的心态，答辩时反而能讲得更透彻。
1. 项目选题思路与技术方案选型
1.1 为什么选“马拉松志愿者管理”这个场景
选毕设题目，我给自己定了三条硬性标准：业务要能讲清楚、角色要足够典型、数据流转要看得见摸得着。
马拉松赛事恰好完美符合。一场马拉松赛事，有赛事主办方、志愿者管理者、志愿者三个核心角色，每个角色对系统都有明确诉求。志愿者要注册、选岗位、看通知、查时长；管理者要负责审核、配岗、排班、统计、物资管理。这些诉求落到系统里就是一个个具体功能模块，每一块都能拿出来单独说设计理念。
更重要的是，这个领域有个天然优势：业务流程完整，但不复杂到做不完。它不像电商系统那样要处理订单状态机、支付回调、库存锁定这些高并发场景，业务核心就是“人”和“时间”两个主线——志愿者档案是一条线，服务时长与岗位分配是另一条线，逻辑清晰，适合我们学生阶段的技术水平去完整落地。
我还考虑过一个痛点：网上能找到的毕设源码，要么是简单的CRUD套壳，要么是游戏、商城这类同质化严重的题目。马拉松志愿者管理这种带有赛事服务业属性的选题，在答辩现场本身就是一个话题点，评委老师也会更有兴趣。只要你能把核心流程讲清楚，这个选题基本不会冷场。
1.2 技术栈选型的核心考量
技术选型上，我最终敲定的组合是SpringBoot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis + Vue 3 + Element Plus。这套组合在目前的毕业设计领域几乎是“标准答案”，但选它的理由不只是因为资料多、好搜答案，背后是有实际考量的。
SpringBoot这一层，我用它最大的感触就是“约定大于配置”。不像早期Spring要写一堆XML配置文件，SpringBoot通过自动配置把大部分重复工作做了，项目启动就能跑起来。官方生态在持续更新，Maven依赖管理、内嵌Tomcat、生产级监控这些能力全都开箱即用。特别提一句，SpringBoot 3.x虽然已经发布很久，但很多第三方库的兼容版本还比较乱，毕设项目我建议老老实实用2.7.x，稳定压倒一切。
持久层我选了MyBatis-Plus，而不是纯MyBatis或JPA。一是它的BaseMapper内置了单表CRUD方法，写志愿者档案、报名记录这类基础接口时省掉大量重复SQL；二是分页插件很成熟，志愿者列表这种典型场景几行代码就能搞定。LambdaQueryWrapper写条件查询，比我手拼SQL安全得多，也避免了“;$%’or 1=1”这种注入问题。
前端采用Vue 3 + Element Plus，是因为项目的页面复杂度不高，但交互上需要表单校验、弹窗提示、表格分页这些常见组件。Element Plus的组件封装得比较完善，写后台管理界面效率高。视图层用Vite构建，相比于Webpack，启动速度快，配置也少，配合代理转发后端接口非常方便。
Redis在这里不是摆设，我用它做了两件核心事情：一是存JWT Token做登录态的无状态校验，二是做服务时长排行榜和公告热点数据的缓存。赛前集中报名那几天，志愿者访问量会突然上来，公告接口高并发查询时，Redis缓存能把数据库压力降一个量级。
1.3 系统角色划分与功能矩阵
系统的用户角色是我在需求分析阶段就定死的：系统管理员和志愿者两个角色，权限边界非常清晰。如果赛事规模更复杂，可以在此基础上再扩展第三方审核人员角色，但核心还是这两类用户。
管理员端功能：
-
志愿者管理：查询、审核、禁用、导出志愿者档案
-
岗位管理：岗位配置、报名截止控制、岗位人数配额
-
签到签退管理：查看打卡记录、处理异常签到单
-
公告管理：发布赛事通知、置顶重要信息
-
数据统计：志愿者报名趋势、服务时长排行、岗位热度分布
志愿者端功能：
-
注册登录：手机号注册、JWT身份认证
-
完善档案：填写紧急联系人、服装尺码、T恤尺寸、过往参赛经验
-
浏览与报名岗位：分赛事查看开放岗位，提交报名申请
-
我的报名：查看审核状态、获取岗位分配结果
-
签到签退：扫码或定位签到，系统记录服务时长
-
我的时长与证书：查看累计服务时长、下载电子证书
-
接收公告：查看系统通知与赛事安排
权限设计核心就一句话：管理员走后台管理路由，志愿者走前台自助路由，两个端不交叉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与核心业务逻辑拆解
2.1 核心数据表结构设计
数据库设计是整个系统的地基，表格没设计好，后面写业务代码全是窟窿。我按业务主线拆出了9张核心表，这里挑最重要的几张给大家逐一讲解。
第一张是志愿者表（volunteer）。这张表既承担账号身份认证职责，也承担个人档案职责。用户名、密码、手机号做登录用，真实姓名、性别、紧急联系人、服装尺码等字段做赛事服务资料用。设计时把is_active字段独立出来，被管理员禁用后用户无法登录，但历史报名记录还能保留，不会破坏关联数据的完整性。
第二张是马拉松赛事表（marathon_event）。一场马拉松是独立赛事，每年可以办春季赛、秋季赛，系统设计上要把赛事作为独立实体管理。赛事名称、举办城市、起跑时间、报名截止时间、赛事状态这些字段都有。注意加了一个赛事编号字段，方便线下纸质物料、参赛包上印编号。
第三张是岗位表（position）。岗位表挂了赛事ID外键，规定了岗位名称、所属赛事、需要人数、已报名人数、岗位描述。核心逻辑是人数校验：报名时先查已报名人数是否小于需要人数，用乐观锁或者事务锁防止超卖。
第四张是报名表（registration）。这是整个系统的核心业务表。每个志愿者对同一赛事同一岗位只能有一条记录。设计上把uniq_volunteer_event作为唯一索引，数据库层面防止重复报名。审核状态字段用枚举值：PENDING、APPROVED、REJECTED。
第五张是签到表（service_checkin），记录志愿者某天某个岗位的签到时间和签退时间，后续自动计算服务时长。签退时间为空表示还未签退，系统在凌晨定时任务里自动处理“忘记签退”的异常单，按岗位结束时间补签并标记为异常。
2.2 报名与岗位分配的完整流程
报名这个功能看似简单，实现起来却要串起好几个逻辑关卡。我把它做成一个带状态流转的完整流程，每一步都有状态记录，这既是业务需要，也是答辩时值得讲清楚的设计点。
志愿者的报名操作触发以下逻辑链路：
-
校验登录态，解析当前用户ID
-
校验志愿者账号状态，被禁用的用户直接拦截
-
校验赛事状态，只有报名中状态才能提交
-
校验岗位是否仍缺人，岗位满员则返回友好提示
-
校验志愿者没有重复报名，命中唯一索引直接报错
-
插入报名记录，状态设为PENDING
-
秒杀式报名场景下，用Redis预扣减岗位剩余名额，异步写库
以上每一步都对应一个独立的校验方法，代码不会挤成一坨。在事务控制上，我是先预扣名额再插入报名记录，如果插入失败回滚扣减。这个流程在高并发场景下，需要仔细权衡数据库事务与Redis一致性的问题。
岗位分配的审核逻辑也有讲究。管理员在后台看到报名列表时，系统会显示志愿者的历史服务时长和过往赛事经验。这算是一个轻量级的“辅助决策”功能，管理员可以根据这些信息优先通过经验丰富的志愿者。分配结果确定后，系统自动触发站内信通知，志愿者登录系统就能看到结果。
2.3 服务时长计算与统计设计
服务时长是志愿者最关心的数据，也是赛事实体机构做激励回馈的依据。这个模块我设计了自动计算 + 手动修正相结合的方式。
自动计算的逻辑是：签到记录表里存sign_in_time和sign_out_time两个时间戳，通过定时任务每小时扫描一次，凡是签退时间不为空的记录，用Duration.between()算出分钟数，再累计到志愿者当日时长。
考虑到现场经常有突发情况，比如志愿者提前离场没签退，或者签到设备故障，所以管理员在后台保留手动补录修正的功能。每次修正都会在修正记录表里留下操作痕迹，保证了数据的可追溯性。
统计展示层面，我做了三个维度的数据：
-
个人维度：志愿者本人看到自己的累计服务时长、参与赛事数量、获得的证书等级
-
赛事维度：单场赛事的时长汇总、人均时长、岗位时长分布
-
排名维度：按月份做时长排行榜，用Redis的ZSet结构存储，应对高并发访问
3. SpringBoot核心模块实现过程
3.1 项目初始化与公共配置
工具准备上，我用的IDEA 2024.1，JDK用的是1.8版本（对应SpringBoot 2.7.x），Maven 3.8.8。为什么强调JDK版本？因为SpringBoot 2.7.x最高只支持到JDK 17，用JDK 21跑2.7.x会直接抛出不兼容异常。如果你用IDEA 2026，创建项目时要注意检查SDK版本，别让工具版本拖后腿。
先在Spring Initializr上生成基础工程，依赖勾选Spring Web、MySQL Driver、Lombok。工程生成后手动引入MyBatis-Plus和JWT相关依赖：
xml复制<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.3.1</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.5</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-impl</artifactId>
<version>0.11.5</version>
</dependency>
需要留意的是，用高版本IDEA时候，SpringBoot版本和依赖版本号必须显式声明，不要依赖Maven默认解析，避免依赖传递错乱导致各种莫名其妙的类找不到异常。
application.yml配置文件是核心，我贴出我当时在用的关键配置：
yaml复制server:
port: 8088
servlet:
context-path: /api
spring:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/marathon_volunteer?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
username: root
password: 123456
redis:
host: localhost
port: 6379
database: 0
mybatis-plus:
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
global-config:
db-config:
logic-delete-field: deleted
logic-delete-value: 1
logic-not-delete-value: 0
jwt:
secret: your-secret-key-your-secret-key-your-secret-key
expire: 604800
端口设为8088是为了避免和前端Vite默认端口5173搞混。context-path统一加了/api前缀，这样前端代理转发时规则只需要匹配/api开头，路由更清晰。逻辑删除配置是MyBatis-Plus的重要特性，配合全局deleted字段，保证线上数据不会误删。
3.2 JWT登录认证与拦截器设计
登录认证方案我对比过Session和JWT，最终选了JWT。核心原因有两点：一是毕设系统的前后端完全分离，前端跑在5173端口，后端跑在8088端口，跨域场景下Session处理麻烦；二是JWT天然无状态，服务器不需要维护Session，水平扩展时不用操心会话同步问题。
JWT工具类里我封装了三个核心方法：生成Token、解析Token、校验Token。生成时把用户ID和角色塞进claims，过期时间设为7天。拦截器方面写了一个JwtInterceptor实现HandlerInterceptor接口，在preHandle方法里解析请求头中的Authorization字段，用Bearer前缀做标识。
java复制public class JwtInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
if (request.getMethod().equals("OPTIONS")) {
return true;
}
String authHeader = request.getHeader("Authorization");
if (authHeader == null || !authHeader.startsWith("Bearer ")) {
throw new BusinessException(401, "未登录或登录已过期");
}
String token = authHeader.substring(7);
Claims claims = JwtUtil.parseToken(token);
request.setAttribute("userId", claims.get("userId"));
request.setAttribute("role", claims.get("role"));
return true;
}
}
跨域问题同样要在WebMvcConfigurer里配置。很多人前后端联调时遇到401或者响应体为空，十有八九是CORS配置遗漏了。必须允许前端地址的跨域请求，允许Authorization请求头，允许GET/POST/PUT/DELETE方法：
java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOriginPatterns("*")
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
.allowedHeaders("*")
.allowCredentials(true)
.maxAge(3600);
}
}
Interceptor注册时要注意排除登录、注册、获取验证码这些白名单接口，否则用户还没登录就被拦截了。
3.3 志愿者注册与档案管理实现
志愿者注册接口的逻辑比较典型，几乎可以当作一个标准的用户注册范式。接口流程是：
-
参数校验，包括手机号格式、密码长度、验证码
-
查询手机号是否已注册，数据库中手机号字段有唯一索引
-
密码加密存储，我用的是BCryptPasswordEncoder，每次加密结果都带随机盐
-
构建志愿者档案记录，同步创建账号记录和档案记录
-
返回脱敏后的用户信息和Token
这里特别说一下密码加密。不少毕设项目直接明文存密码，答辩时被老师问一句“密码泄露了怎么办”就很难回答。BCrypt是Spring Security里现成的加密器，单拿出来用接口也很简单：
java复制@Service
public class VolunteerServiceImpl implements VolunteerService {
@Override
@Transactional(rollbackFor = Exception.class)
public RegisterResult register(RegisterRequest request) {
// 校验验证码
String cacheCode = redisTemplate.opsForValue().get("sms:code:" + request.getPhone());
if (cacheCode == null || !cacheCode.equals(request.getCode())) {
throw new BusinessException("验证码错误或已过期");
}
// 校验手机号唯一
Long count = volunteerMapper.selectCount(
new LambdaQueryWrapper<Volunteer>().eq(Volunteer::getPhone, request.getPhone())
);
if (count > 0) {
throw new BusinessException("该手机号已注册");
}
// 密码加密入库
Volunteer volunteer = new Volunteer();
volunteer.setPhone(request.getPhone());
volunteer.setPassword(passwordEncoder.encode(request.getPassword()));
volunteer.setStatus(1);
volunteer.setCreateTime(LocalDateTime.now());
volunteerMapper.insert(volunteer);
// 签发Token
String token = JwtUtil.generateToken(volunteer.getId(), "VOLUNTEER");
return new RegisterResult(token, volunteer.cleanSensitiveInfo());
}
}
@Transactional(rollbackFor = Exception.class)这个注解不可少。注册流程涉及多个表写入，如果不加事务，中间任何一步报错都可能导致数据不一致。有一个坑是，SpringBoot 2.7的默认事务管理器只对RuntimeException生效，若把rollbackFor设为Exception.class，即可兼容所有异常类型。
档案管理功能则侧重于信息的完整性维护。我加了一个progress字段来记录档案完成度，每次志愿者编辑完基本信息后，系统计算必填项的完成比例，低于60%时在页面上醒目标出“请完善档案信息以便岗位审核”。这个设计在一定程度上提高了数据的可用性，实际使用的反馈也很正向——很多志愿者会主动补完紧急联系人和服装尺码。
3.4 岗位报名接口与防超卖处理
报名接口是整个系统里最容易出并发问题的模块。想象一个场景：热门岗位名额50人，开报瞬间100个志愿者同时点击报名，如果代码不加以控制，最终报名成功的人数可能远大于50。
防超卖的方案我做了两层：
第一层，Redis预扣减。岗位报名前，先把岗位剩余名额加载到Redis，用DECR原子操作扣减。如果扣减后的值小于0，直接返回“名额已满”。这个操作是原子性的，并发环境下不会超卖。第二层，数据库兜底。Redis扣减成功后再执行数据库写入，写入时用UPDATE语句带条件更新岗位表，将已报名人数加1，但要求加1后不超过岗位人数上限：
sql复制UPDATE position
SET registered_count = registered_count + 1
WHERE id = #{positionId}
AND registered_count < max_count
如果更新影响行数为0，说明此时数据库层面名额已满，需要补一条异常日志并把Redis名额加回去。
Redis预扣减代码如下：
java复制public Boolean tryAcquirePosition(Long eventId, Long positionId) {
String key = "position:quota:" + eventId + ":" + positionId;
Long remain = redisTemplate.opsForValue().decrement(key);
return remain != null && remain >= 0;
}
这里踩过一个坑：忘记处理Redis与数据库的双写一致性。如果数据库更新失败但Redis已经扣减，会导致Redis库存数据不准确。兜底方案是定时任务每隔5分钟，把数据库实际名额同步回Redis，让Redis值修正。这套方案写进论文里，能占不少篇幅。
3.5 文件上传与MinIO云存储集成
志愿者需要上传头像、身份证照片，管理员需要上传赛事物料图片、公告附件。文件上传我直接用了MinIO做对象存储。选择MinIO的理由很简单：部署比FastDFS简单得多，API兼容亚马逊S3，社区资料充足，而且毕业设计要求不会涉及十几PB的海量存储，MinIO够用。
MinIO加进SpringBoot的方式，核心是在pom.xml中引入依赖，然后配置MinioClient的Bean：
xml复制<dependency>
<groupId>io.minio</groupId>
<artifactId>minio</artifactId>
<version>8.5.7</version>
</dependency>
java复制@Configuration
public class MinioConfig {
@Value("${minio.endpoint}")
private String endpoint;
@Value("${minio.access-key}")
private String accessKey;
@Value("${minio.secret-key}")
private String secretKey;
@Bean
public MinioClient minioClient() {
return MinioClient.builder()
.endpoint(endpoint)
.credentials(accessKey, secretKey)
.build();
}
}
上传文件的逻辑封装在FileService里，核心流程三步：检查bucket是否存在，不存在就创建；生成唯一文件名，规则是日期 + UUID + 原始扩展名；执行putObject上传并返回URL。
文件类型校验这里要重点提醒一下：接口层只接收图片后缀是不够的，攻击者完全可以改后缀上传恶意脚本。我额外校验了文件的Content-Type和文件头魔数，比如JPEG文件的十六进制头是FF D8 FF，PNG文件是89 50 4E 47。拿到文件后先读前几个字节判断真实类型，再决定是否允许上传。
3.6 数据可视化与图表统计实现
毕业设计想要在答辩时有亮点，数据可视化是一个性价比很高的模块。我用ECharts做图表渲染，前端通过Vue封装了一个统一图表组件，根据后端返回的数据类型切换柱状图、折线图、饼图。
展示的统计指标包括：
-
各赛事报名人数对比（柱状图）
-
单赛事每日新增报名趋势（折线图）
-
岗位类型分布占比（饼图）
-
志愿者服务时长Top20排行（横向条形图）
后端统计接口用SQL的GROUP BY聚合查询搞定，Mapper方法返回Map数据。以赛事报名趋势为例：
xml复制<select id="selectDailySignupTrend" resultType="java.util.Map">
SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS date,
COUNT(*) AS count
FROM registration
WHERE event_id = #{eventId}
AND create_time >= #{startTime}
GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d')
ORDER BY date
</select>
热点数据接口加了Redis缓存，缓存时间为60秒。比赛前一周报名高峰期，志愿者反复刷新页面看报名详情时，这个缓存能挡住90%以上的重复SQL查询。
4. 系统测试与部署调优实战
4.1 后端接口测试与常见问题排查
系统开发完成后，进入到了联调测试阶段。这个阶段发现的问题最多，总结几个我实际遇到的典型案例。
第一个是“JSON序列化循环引用导致接口报500”。志愿者实体关联了报名列表，报名列表又关联了赛事，赛事又关联岗位。默认的Jackson序列化会把关联对象全部递归序列化，直接栈溢出。解决方法是，在实体类的关联字段上标注@JsonIgnoreProperties，或者使用@JsonIgnore忽略不需要返回的字段。
第二个是“MyBatis-Plus分页失效”。这个坑很经典，很多人写完分页查询发现返回的总记录数始终为0，或者查询结果不带分页效果。原因是忘记添加分页插件配置类。必须在项目中显式声明MybatisPlusInterceptor的Bean，并添加PaginationInnerInterceptor。
java复制@Configuration
public class MybatisPlusConfig {
@Bean
public MybatisPlusInterceptor mybatisPlusInterceptor() {
MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
return interceptor;
}
}
第三个是“前端Vite代理配置错误导致请求404”。本地开发环境中，前端跑5173端口，需要把/api开头的请求代理到后端8088端口。vite.config.js里配置server.proxy：
js复制export default defineConfig({
server: {
port: 5173,
proxy: {
'/api': {
target: 'http://localhost:8088',
changeOrigin: true
}
}
}
})
如果这里没配好，前端加载时接口直接404，页面空白，排查起来容易走弯路。
4.2 项目部署与上线过程记录
部署方案我用了前后端分离的标准做法：前端打包成静态文件部署到Nginx，后端用JAR包部署到服务器，Redis和MySQL各自独立部署。Nginx负责接收浏览器请求，把/api路径的请求反向代理到后端8088端口，其他路径直接访问前端静态资源。
前端打包命令是npm run build，生成dist目录。dist里的文件上传到服务器/usr/share/nginx/html目录。Nginx配置文件里最关键的是location块的处理：
nginx复制server {
listen 80;
server_name your-domain.com;
location / {
root /usr/share/nginx/html;
index index.html;
try_files $uri $uri/ /index.html;
}
location /api/ {
proxy_pass http://localhost:8088/api/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
try_files配置非常重要，Vue是单页面应用，浏览器刷新某个子路由时，Nginx要能正确回退到index.html，否则会出现页面刷新404的情况。
后端JAR包的启停，我用的是Systemd服务方式，比手工java -jar启动更靠谱，服务器重启后服务能自动拉起。Systemd服务配置核心内容如下：
ini复制[Unit]
Description=Marathon Volunteer API Server
After=network.target
[Service]
User=root
WorkingDirectory=/opt/marathon
ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar marathon-volunteer.jar
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
上线压测时有个数据值得分享：单机配置2核4G，MySQL + Redis跑在同一台服务器上，用JMeter模拟500个并发用户执行报名操作，接口平均响应时间在326ms，错误率0.2%，QPS在380左右。对毕设级别的系统来说，这个性能表现已经非常够用。
4.3 数据库备份策略与初始化脚本
数据安全是任何管理系统都绕不开的话题。我在design阶段就把数据库初始化脚本和备份脚本一并做完了。初始化脚本里包含建库、建表、初始管理员账号、演示数据四部分，方便答辩时快速重置演示环境。
备份策略采用每天全量备份 + binlog增量备份的方式。全量备份用mysqldump命令，写成了Shell脚本配合crontab定时执行：
bash复制#!/bin/bash
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
mysqldump -uroot -p123456 marathon_volunteer > "$BACKUP_DIR/volunteer_$DATE.sql"
find "$BACKUP_DIR" -type f -mtime +30 -exec rm {} \;
脚本里加了一步自动清理30天前的备份文件，避免磁盘被备份文件占满。设置每天凌晨2点执行：0 2 * * * /opt/scripts/backup_mysql.sh。
恢复测试也建议实际操作一遍，毕设验收时老师可能随机挑一个时间点的数据问你是否能恢复。我的实践流程是：把备份文件拷贝到测试库，执行source命令导入，再通过对比指定记录的创建时间来验证数据完整度。这个流程走顺了，答辩时你能展现出真实的工程素养。
5. 经验心得与扩展建议
整个项目从零到上线，我前后花了三周时间，每天平均投入四到五个小时。这个周期包含了需求梳理、数据库设计、前后端开发、测试调优和文档编写。如果你是从头开始做，我建议时间规划上留出缓冲，前期的需求分析和表结构设计很关键，这部分想清楚了代码写起来很快就顺。
答辩环节的经验是：老师问到“为什么这么设计”的时候，一定要说出取舍的逻辑。比如为什么不用Session而用JWT，为什么引入Redis，为什么做逻辑删除而不是物理删除。每一个取舍点背后都有真实的技术原因，把原因讲清楚，比你背一百个概念都有说服力。论文里还可以补充性能对比数据，比如并发报名场景下有无Redis的响应时间对比，这些实测数据是加分项。
后续扩展方向上，这个系统还能做很多事：接入地图API实现志愿者位置签到，增加消息推送模块做到点对点通知，加入赛事成绩查询功能复用现有志愿者体系，或者引入GPT做一个赛事问答机器人。骨架干净的项目就是这样，想往哪个方向延展都有路可走。
我个人最后的一点体会是：毕设源码真的不要图省事直接拿别人的跑一下就算完了。花时间从头把系统实现一遍，你收获的不只是一份能交差的代码，还有从问题到方案、从方案到代码的完整思维链路。这套能力，在后来的面试和工作中，一直让我受益。