1. 项目拆解：志愿者服务平台到底在做什么
先把这个项目说清楚。所谓“Java志愿者服务平台APP”，本质上就是一个连接志愿者、志愿组织和志愿活动管理方的移动端应用。放在毕设场景里，它解决的问题非常具体：志愿者怎么注册、怎么找活动、怎么报名、怎么记录服务时长；组织方怎么发布活动、怎么审核报名、怎么统计工时。这些流程在线下靠表格和微信群硬撑没问题，但一旦志愿者数量上百、活动频率上来，管理就会乱成一锅粥。所以这个项目的核心价值就是——把志愿服务的全流程搬到线上，让每个环节都有迹可循、可查、可统计。
从毕设选题的角度看，这个方向之所以热门，是因为它具备一个“好毕设项目”的所有特征：业务逻辑清晰但不简单，涉及用户、活动、报名、时长、公告、评论等多个实体；技术栈覆盖广，后端能用到前后端分离、权限认证、文件上传、数据统计，前端能用到列表、表单、状态切换、地图定位；同时它自带真实的应用场景，答辩的时候很容易讲清楚“我做了什么、解决了什么问题”。
再说说这个项目标题里那句“可做计算机毕设Java、Python、PHP、小程序APP、C#、爬虫大数据、单片机”的含义。很多同学看到这里会困惑：一个志愿者平台，怎么还能扯上单片机？实际上这只是源码卖家的一种通用话术，用来覆盖所有主流毕设需求。真正核心的还是“Java后端 + APP前端”这条主线，其他技术栈只是基于同一套业务模型做了语言迁移。比如Python版会用 Django/Flask 替代 Spring Boot，PHP版用 Laravel/ThinkPHP，小程序版则把APP端换成微信小程序。
这里要给你一个明确的建议：如果你是想认真做一个拿得出手的毕设，优先选Java版。原因后面细说，先记住结论——Java版生态最完整、学习资料最多、扩展性最强，无论是自己二次开发还是答辩演示都最稳妥。
2. 为什么这个选题在毕设里几乎是“安全牌”
2.1 业务模型天然适合毕业设计
志愿平台这个业务，最大的优势是“人人都能理解”。答辩的时候，评委老师不需要你解释什么是志愿服务，他本人在生活中就接触过。这就省掉了一大半沟通成本。相比之下，如果你做一个“基于深度学习的某某检测系统”，还得先费口舌解释模型原理；而志愿者平台，你说第一句话“我要做一个方便志愿者报名活动、记录时长的APP”，评委立刻就知道你在做什么。
另外，这个业务模型的复杂度刚刚好。它比“学生管理系统”这种烂大街的题目多了一层业务深度（审核流程、时长统计、多角色权限），又比“电商系统”少了支付、库存、物流这些容易失控的环节。五个核心表（用户、活动、报名、时长、公告）加上两个关联表（组织成员、活动评论），这个规模写进毕业论文里不多不少，既有内容可写，又不会把自己累死。
2.2 技术栈刚好踩在评分点上
毕业论文评分通常看几个要素：工作量、技术难度、完成度、创新点、答辩表现。Java志愿者平台在这个结构里几乎全部命中。
工作量方面：需要实现前后端两套代码，再加上数据库设计文档、系统测试报告、论文正文，至少能达到毕业设计的基本字数和代码量要求。
技术难度方面：核心难点集中在角色权限控制、状态流转（比如活动从“招募中”到“进行中”再到“已结束”）、时长统计的准确性，这三个点每一个都能写出一小节技术实现，不用硬凹深度。
创新点方面：不用做什么人工智能，你只要在系统里加一个“志愿时长排行榜”或者“活动日历视图”，就能在答辩时多一个亮点。这些东西不复杂，但别人没做，你做了，就是加分项。
2.3 资源多、容错率高
毕设周期一般是三个月到半年，中间你还要实习、上课、找工作，真正能投入到项目上的时间很有限。Java志愿者平台这种经典题目，网上能找到的参考代码、设计文档、论文模板非常多。遇到实在搞不定的技术点（比如Redis缓存击穿、JWT过期处理），随便一搜就有一堆现成方案。这意味着你不太可能因为“这个功能不会做”而卡死，最多是需要一些时间消化理解。
但这里有个非常重要的提醒：源码可以借鉴，但一定要自己跑通、自己改过。我见过很多同学直接下载一套源码交上去，结果答辩时老师随便问一句“你的登录token存在哪里”“活动状态是在前端判断还是后端判断”，就答不上来，直接被判定为抄袭。所以哪怕你从零写不出来，也至少要保证：每一行核心代码都知道是干嘛的，并且能独立完成环境的搭建和部署。
3. 系统功能设计与数据库建模实战
3.1 角色权限体系：这套系统的骨架
志愿者平台最核心的设计决策，就是怎么划分角色。我的建议是采用“三端两角色”模型，具体来说：
- 前端用户端：面向志愿者和普通游客，提供注册登录、活动浏览、活动报名、我的报名、个人中心、志愿时长查询。
- 前端组织端：面向志愿组织/管理员，提供活动发布、活动审核、报名审核、时长录入、成员管理、数据统计。
- 后端管理端（通常用Web页面）：面向超级管理员，负责系统配置、用户管理、组织认证、全局数据看板。
对应到技术实现上，就是一套登录认证体系加两套前端界面。Java后端统一提供REST API，用户端APP和PC管理后台共用同一套接口。这样设计的好处是代码复用率高，你只需要写一遍业务逻辑，然后分别开发两套前端调用。
权限控制我推荐用Spring Boot的拦截器 + JWT（JSON Web Token）方案，不需要引入Spring Security那种重型框架。JWT把用户ID、角色存进token里，每次请求由拦截器解析token、校验角色、放行或拦截。这个方案工程量小，而且你可以在毕业论文里写清楚“为什么不用Session而用JWT”——因为移动端无状态、跨端共享、天然支持分布式部署，这个小知识点在答辩时非常好用。
3.2 数据库表设计：五张核心表怎么建
数据库设计是这种管理系统类毕设的重头戏，也是论文里篇幅最长的部分。直接给出我推荐的表结构，以及每张表的关键字段和设计理由。
用户表（sys_user）
这是底表，存所有账号信息。字段包括：id、用户名、密码（BCrypt加密存储）、昵称、手机号、头像、角色（3=超级管理员，2=组织管理员，1=志愿者）、创建时间、状态（1正常，0禁用）。
这里要说一个容易踩的坑：不要把密码明文存进数据库。哪怕只是毕设，答辩老师看到你密码是明文，印象分会大打折扣。用Spring Security自带的BCryptPasswordEncoder加密存储，代码量很少，但专业性立刻提升一个档次。
志愿组织表（org_info）
普通志愿者想成为组织成员，需要先申请创建组织，由超级管理员审核通过后才能发布活动。字段包括：组织id、组织名称、简介、负责人用户id、LOGO、审核状态（0待审，1通过，2驳回）、创建时间。
志愿活动表（activity_info）
这是整个系统的业务中心。字段包括：活动id、活动标题、活动详情（富文本）、活动地点、活动开始时间、结束时间、招募人数、已报名人数、活动状态（0招募中，1名额已满，2进行中，3已结束）、发布组织id、封面图、签到码。
在这里特别强调一个设计细节：活动状态的判断不要依赖定时任务去“修改”状态字段，而是通过“活动开始时间是否小于当前时间、报名人数是否达到招募人数”动态计算得出。比如前端要判断活动能不能报名，只需要传当前时间戳给后端，后端返回一个status字段。这样代码更健壮，不会因为服务器断电或定时任务没跑就导致状态错误。
报名记录表（sign_up_record）
这个表解决“谁能参加活动”的问题。字段：记录id、活动id、用户id、报名时间、签到状态（0未签到，1已签到）、签到时间。要设置唯一索引（activity_id, user_id），防止同一用户重复报名同一活动，这个唯一索引是防止并发问题的关键。
志愿时长表（volunteer_hour）
记录志愿者每次活动的服务时长。字段：id、用户id、活动id、时长值（单位：小时，保留1位小数）、录入人（组织管理员id）、录入时间。
时长数据怎么来？这里要设计一个规则：在活动开始当天，由组织管理员在“活动详情页”点击“开始签到”，志愿者在APP上输入活动签到码完成签到；活动结束后，管理员根据签到名单批量录入时长。这个流程本身就涉及两个状态：签到记录和时长记录。简单起见，时长表可以单独添加，不用和签到记录强关联，但要保证“一个活动只能给一个志愿者录一次时长”——所以表结构里同样要加唯一索引（user_id, activity_id）。
3.3 几张辅助表：让系统更像真实产品
只有五张表确实能跑通，但为了让项目在答辩时有更多可讲的点，建议再加几张辅助表：
- 公告表（notice_info）：管理员发布系统公告，APP首页滚动展示。字段简单，但能体现“消息触达”的设计思路。
- 评论表（comment_info）：志愿者在活动详情页留言提问，组织方回复。这能增加互动性，也是扩展“社区感”的一个抓手。
- 消息通知表（message_info）：报名成功后推送给用户一条通知。如果不想引入消息队列那么重的东西，可以在报名接口里同步插入一条消息记录。
这些辅助表的技术难度都不高，但能大幅提升系统的完整度。写论文时，多一张表就多一节数据表设计内容，多一个接口就多一段代码展示，工作量积累起来，论文的查重率也能被稀释。
4. 核心后端功能实现：从登录到报名全链路
4.1 项目初始化与依赖选型
用Spring Initializr初始化项目，或者直接用IDEA新建Spring Boot工程。Java版本我建议用JDK 8或JDK 11，兼容性最好，不要一上来就上JDK 17及以上，部分老教程会水土不服。
核心依赖清单如下（Maven坐标简写）：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.19.2</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency>这里有几个选择说明。MyBatis-Plus比原生MyBatis多了一堆现成的CRUD方法，写单表查询基本不需要自己写SQL，极大提升开发效率；JWT选用auth0的java-jwt，比jjwt更简洁；校验框架用spring-boot-starter-validation，可以在DTO上直接加@NotNull、@NotBlank注解，免去一长串if判断。
注意，Lombok虽然有争议，但在毕设项目里可以使用，因为它能让实体类代码大幅缩短，论文里核心代码展示更聚焦。你只需要在IDEA里装好Lombok插件编译就通了。
4.2 JWT登录认证：这个环节写不好必被问
登录逻辑是整个后端最基础也最容易在答辩时被追问的模块。基本流程是三步：用户输入账号密码→校验通过后生成token→前端把token存起来，后续每个请求在Header里带上。
先写一个JwtUtil工具类，负责生成和解析token：
public class JwtUtil { private static final String SECRET = "your-secret-key"; public static String createToken(Long userId, Integer role) { Algorithm algorithm = Algorithm.HMAC256(SECRET); String token = JWT.create() .withClaim("userId", userId) .withClaim("role", role) .withExpiresAt(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .sign(algorithm); return token; } public static DecodedJWT parseToken(String token) { return JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token); } }然后是拦截器，拦截所有除登录注册外的请求：
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException("未登录"); } try { DecodedJWT jwt = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", jwt.getClaim("userId").asLong()); request.setAttribute("role", jwt.getClaim("role").asInt()); } catch (JWTVerificationException e) { throw new BusinessException("token无效或已过期"); } return true; } }再把拦截器注册到Spring配置里，指定放行路径：/api/auth/login、/api/auth/register、/api/activity/list等公开接口。这样简单的两段代码，就实现了“无状态认证”的核心机制。写论文的时候，把这段代码一贴，再配上“基于JWT的无状态认证设计”小节，就是很完整的篇幅。
4.3 报名接口：并发与幂等性怎么处理
报名活动是系统里最容易出Bug的接口。核心问题有三个：用户重复报名、活动名额已满、并发状态下的数据错乱。
解决方案对应为三层防线。第一层是数据库层，在报名记录表建立（activity_id, user_id）唯一索引，从物理上杜绝重复插入。第二层是业务层，报名前先查询（如果查询发现已经存在记录，直接抛出“请勿重复报名”）。第三层是并发优化，用分布式锁相对复杂，毕设阶段可以用乐观锁解决：
@Update("UPDATE activity_info SET sign_up_count = sign_up_count + 1 " + "WHERE id = #{activityId} AND sign_up_count < recruit_count") int increaseSignUpCount(@Param("activityId") Long activityId);这段更新的巧妙之处在于，如果不是“已报名人数小于招募人数”，那么更新影响行数为0，根据这个结果直接返回“活动名额已满”。整个操作在数据库层面是原子性的，不需要额外的锁机制，代码简单且正确。
下面给出报名接口的完整实现思路：
@PostMapping("/sign/up") public Result signUp(@RequestBody SignUpRequest request) { Long userId = (Long) request.getAttribute("userId"); // 1. 校验活动状态 ActivityInfo activity = activityService.getById(request.getActivityId()); if (activity.getStatus() == 4) { // 已结束 return Result.error("活动已结束"); } // 2. 尝试参与人数递增（数据库原子操作） int rows = activityMapper.increaseSignUpCount(request.getActivityId()); if (rows == 0) { return Result.error("活动名额已满"); } // 3. 插入报名记录（若重复则抛出DuplicateKeyException） SignUpRecord record = new SignUpRecord(); record.setActivityId(request.getActivityId()); record.setUserId(userId); signUpRecordService.save(record); // 4. 插入消息通知 messageService.sendMessage(userId, "您已成功报名：" + activity.getTitle()); return Result.ok(); }这个接口虽然短，集中体现了对数据库约束、业务校验、异常容忍的综合运用。答辩时，能把这个接口从头到尾讲明白，基本就能证明你真的写过代码。
4.4 文件上传：头像和活动封面的标准解法
头像和活动封面图是这种平台型项目的标配功能。不建议把图片直接存数据库的Blob字段，更不建议用Base64编码塞进JSON。标准做法是：后端接收MultipartFile，保存到服务器的指定目录（比如/upload），同时返回访问路径；再把路径存进数据库对应字段。
@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { // 1. 校验大小与类型，限制5MB以内，jpg/png格式 if (file.getSize() > 5 * 1024 * 1024) { return Result.error("文件过大"); } String originalName = file.getOriginalFilename(); String ext = originalName.substring(originalName.lastIndexOf(".")); // 2. 使用UUID生成新文件名，避免重名覆盖 String newName = UUID.randomUUID().toString() + ext; // 3. 按日期目录存储：/upload/20250520/newName.jpg String dateDir = new SimpleDateFormat("yyyyMMdd").format(new Date()); File dir = new File(uploadPath + "/" + dateDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, newName)); // 4. 返回可访问的URL路径 return Result.ok("/upload/" + dateDir + "/" + newName); }这里有一个毕设阶段很少被注意但答辩会被问到的点：访问路径需要配置静态资源映射。Spring Boot默认的静态资源目录是classpath:/static/，你存在磁盘根目录的upload文件夹，必须手动指定映射。在配置类里加一行即可解决：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourcePatterns("file:" + uploadPath + "/"); }4.5 数据统计接口：用一条SQL解决排行榜
志愿时长排行、活动参与人数统计是给系统加分的模块。很多同学会把数据查出来然后在PHP逻辑里循环统计，效率极低且代码难看。正确方式是用聚合查询。
志愿者时长排行，本质上就是想对volunteer_hour表按user_id分组、求和、排序，MyBatis-Plus的QueryWrapper + selectMaps就可以：
List<Map<String, Object>> rankList = volunteerHourMapper.selectMaps( new QueryWrapper<VolunteerHour>() .select("user_id, SUM(hour_value) as total_hours") .groupBy("user_id") .orderByDesc("total_hours") .last("LIMIT 10"));再用用户表补上名称和头像，就能得到完整的排行榜数据。这条SQL在数据库层面已经完成了全部计算，后端只是搬运工，效率远高于循环累加。数据库是干这个用的，别用代码扛。
同理，首页要展示四个数据卡片（用户总数、组织总数、活动总数、总服务时长），也全部可以用聚合查询一步得出。这个思路写进论文“系统预测统计”部分，绝对亮眼。
5. APP前端与前后端联调的关键细节
5.1 技术选型：原生Android还是uni-app
前端是整个项目工作量的大头。毕设场景下我的建议排序是：原生Android > uni-app（打包为APP） > Flutter > 微信小程序。
为什么不推荐直接在Android Studio里用Java/Kotlin从零写原生？因为原生开发的UI搭建、屏幕适配、调试流程都比较耗时，一个没有移动端经验的人光是把列表页、详情页、个人中心三个页面调好就得费不少时间。
更适合的路线是：用uni-app基于Vue 3语法开发，一套代码可打包为Android APP、iOS APP、H5和微信小程序。这样你写一套前端代码，答辩时可以同时演示APP和H5，功能一样但给人的直观冲击完全不同。而且uni-app的基础组件与微信小程序高度相似，学习曲线比原生Android平缓很多。
5.2 uni-app中请求封装与token管理
前端最核心的公共代码有两块：请求封装和登录态管理。
项目request.js文件里，统一封装uni.request并做三件事：拼接BaseURL、附带Authorization请求头、统一处理token过期后的重定向登录逻辑。核心代码长这样：
const BASE_URL = 'http://192.168.1.100:8080/api'; export function request(url, method, data) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + url, method: method || 'GET', data: data, header: { 'Authorization': 'Bearer ' + uni.getStorageSync('token'), 'Content-Type': 'application/json' }, success: (res) => { if (res.data.code === 401) { uni.removeStorageSync('token'); uni.reLaunch({ url: '/pages/login/login' }); reject(res.data); } else { resolve(res.data); } }, fail: (err) => { reject(err); } }); }); }这段代码解决的是“以后的所有接口都不用再手动带token”的问题。你只需要在每个页面调用request方法，它自动携带登录凭证。token过期的场景是被动处理：后端返回401，前端自动清除缓存并跳回登录页。
5.3 前端页面设计：五个页面撑起整个APP
APP端的页面不需要很多，五个核心页面足够支撑完整流程：
- 首页（Home）：轮播图 + 活动列表（按时间排序）+ 公告滚动条。
- 活动详情页：展示活动内容、剩余名额、报名按钮、评论区。
- 我的报名页：列表展示当前用户的报名记录，用不同颜色标签区分“待参与/已完成”。
- 个人中心页：用户信息、累计时长大卡、我的组织入口、设置按钮。
- 组织管理页：管理员专属，活动发布表单、报名审核列表、时长录入入口。
组织管理用了一个H5页面嵌入APP容器的方案或直接在APP里单独划分一个Tab，看自己开发时间决定。我的建议是如果时间紧张，管理端可以只用PC Web页面，APP端只需要把“志愿者C端”走通，更聚焦也更合理。
5.4 前后端联调时的经典坑
联调是最耗费时间的环节。这里把我踩过的一些高频坑直接列出：
- 跨域问题：前端开发时通过HBuilderX内置浏览器访问接口，会触发跨域。后端在配置类里必须加CORS跨域支持，否则接口全部不可用。
- 网络地址问题：不要在接口地址里写localhost，安卓模拟器访问电脑要用10.0.2.2（不过新版本模拟器也可能用局域网IP），真机调试必须填电脑的局域网IP，且手机和电脑同一WiFi。
- 时间格式问题：后端返回LocalDateTime，前端拿到可能是数组形式的序列化结果。在实体类的日期字段上加上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")即可。
- 图片路径问题：前端显示图片时，图片地址如果是相对路径（/upload/xx.jpg），必须拼接上服务器IP前缀。建议在后端统一返回完整路径，或在全局配置一个图片地址前缀，避免每个页面单独处理。
6. 答辩与论文的核心策略：怎么把75分的项目讲成85分
6.1 论文结构怎么安排最省力
毕业设计论文通常有固定的结构要求，大体包含摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结与展望。对应到志愿者平台，重点工作分配如下：
- 需求分析章节：画用例图（管理员、组织、志愿者三个角色），列功能需求清单和性能需求。这部分把功能列表写全即可，多拿交互流程描述凑内容。
- 系统设计章节：重点放架构图、功能模块划分、数据库ER图和表结构说明。每张表配上字段说明表，轻松写满十页。
- 系统实现章节：选择关键模块贴代码，重点是JWT认证、活动发布、报名事务、时长统计这四处。避免全篇贴代码，用“功能描述 + 核心代码 + 实现效果截图”三段式，每一小节都能写出一页半。
- 系统测试章节：功能性测试按模块列测试用例，性能测试可以用JMeter跑一次并发报名，截个聚合报告图。能写出并发压测报告的项目，在答辩老师眼里印象分会上一档。
6.2 答辩现场演示的最优路径
现场演示顺序不要按开发顺序来，要按照“讲故事的逻辑”安排：
第一步，演示超级管理员登录后台，创建并审核一个志愿组织。这展示了多角色管理。 第二步，切换到用户端APP，注册一个新志愿者账号，浏览首页活动，完成报名。这展示了平台核心流程。 第三步，切回组织管理员账号，看到报名列表，模拟审核通过，录入志愿时长。这展示了管理闭环。 第四步，回到志愿者个人中心，看到时长数据更新，再打开排行榜页看到自己上榜。这构成了一个完整的业务闭环。
整个演示过程不到五分钟，但涵盖了全部核心模块，节奏紧凑、逻辑自洽，比漫无目的地点来点去好得多。一定要提前演练两遍，确保每一步点的页面都能按预期出现，现场卡壳是答辩大忌。
6.3 口头答辩问题清单：这些问题先自测
根据我个人多年参加毕设评审的经验，评委对管理系统类项目最喜欢问的问题集中在几个方向。先自己能不能答上来：
- 为什么用JWT而不用Session？两者在移动端的区别是什么？JWT过期时间设置成多久，为什么？
- 活动状态是实时计算的还是数据库字段？如果志愿者人数刚满又有人取消报名怎么办？（注意：这个问题隐藏得很深，建议报名表加一个取消报名接口，把报名人数减回去）
- 一个志愿者如果重复报名同一个活动，你怎么防止？数据库层面和代码层面分别怎么拦？
- 志愿时长是谁录入的？如何防止组织管理员乱录时长？
- 数据库表之间是几对几关系？外键为什么不用？
这些问题只要在答辩前把代码和表结构重新过一遍，是最容易准备的。别抱侥幸心理，哪怕只被问到“怎么防止重复提交报名”这一个问题，答不出都很难圆场。
7. 常见问题排查与开发心得实录
7.1 环境搭建期的经典报错
第一个必踩的坑是Maven依赖下载慢或失败。解决方案：在Maven的settings.xml里配置国内镜像源。另外，有些同学的JDK版本和Spring Boot版本不匹配，比如用JDK 17跑Spring Boot 2.x版本，编译没问题但运行时会出现模块访问报错。建议统一使用JDK 8 + Spring Boot 2.7.x组合，稳如老狗。
第二个常见问题是启动Spring Boot时端口被占用。直接改application.yml里的server.port为8081或自定义端口即可，顺便也能避免前后端联调时的端口冲突。
7.2 数据库层面的疑难杂症
MySQL 8.x连接驱动配置和5.x不同，在pom.xml中要用com.mysql:mysql-connector-j，并且URL里要加上serverTimezone=Asia/Shanghai参数，否则日期字段永远差八个小时。
另一个宗见现象：明明数据表里有记录，MyBatis-Plus查询却返回空。十有八九是实体类字段和数据库字段的驼峰映射没生效。在application.yml里配置mybatis-plus.configuration.map-underscore-to-camel-case: true即可解决。
涉及到统一事务管理，建议在启动类上添加@EnableTransactionManagement注解，然后在报名接口上标注@Transactional。不做这一步的话，如果“报名记录插入”成功但“活动人数递增”失败，会导致数据不一致，这是系统中非常严重的数据正确性问题。
7.3 前端真机调试不出图的排查顺序
真机上一运行，图片全挂、接口全挂，这种事我遇到过好几次。排查顺序建议按三步走：
第一步，检查手机和电脑是否在同一局域网，用手机浏览器直接访问你的后端IP+端口，能出JSON说明网络通。 第二步，检查后端接口是否是POST且要求JSON格式，uni-app默认请求头如果没指定Content-Type为application/json，后端会直接报415错误。 第三步，检查Android 9以上系统是否默认禁止HTTP明文流量，必须在uni-app的manifest.json中设置“Android启动模式”或通过网络安全配置允许HTTP访问。这一步是最容易忽略的，报错信息还可能很隐晦。
7.4 关于“免费领源码“的理性态度
最后回答一个绕不开的问题：那些“免费领源码”的资源，到底能不能用？
我的建议是：可以用于学习和参考，但不要直接上交。一套免费源码的质量参差不齐，有的能跑，有的根本是半成品。即使能跑，代码风格、命名规范、注释质量可能都不满足毕业设计论文的要求，硬套上去反而要花更多时间排查。
正确使用方法是：先通读一遍源码中的核心模块（登录、权限、报名、数据统计），理解它的整体结构；然后自己从零把这个系统重写一遍，或者基于源码做大幅修改，改表结构、加功能、换前端页面。这样既能借助源码缩短开发周期，也能保证交付的内容自己烂熟于胸，真正达到了毕业设计的目的——不是“做出来”，而是“学会了”。
就我个人经验来说，毕设这件事最忌两头不靠：既想省事直接用别人的，又担心答辩露馅，结果焦虑了整个周期。与其这样，不如豁出去从跑通一个最简单的登录注册开始，一步一步往上加功能，等你把报名和时长统计调通的那一刻，那种成就感远比“下载一套代码交差”来得踏实很多。这个项目足够经典，也足够练手，照着上面的思路去做，拿一个不错的结果并不难。真的卡住了，就回头把第四章的接口实现再过一遍，大多数所谓“难题”，其实只是你还没找到下手的位置而已。
