作为每年要过目几十个SpringBoot毕业设计的人，第一次看到“校园志愿者服务管理系统”这个题目，我就觉得它比常见的商城系统、图书管理系统都更适合拿来当毕设。它业务不绕，但链路完整：用户、角色、活动、报名、签到、时长审核、积分排行、数据统计，一条线串下来，正好把SpringBoot、MyBatis-Plus、Redis、Vue这些技术栈都用上。而且从“智慧校园公益服务信息化系统”这个角度切入，除了能写代码，还能讲出点数字化管理的实际意义，答辩时也更容易站得住。

这篇文章我会按实际开发顺序，把整个项目从需求拆解到上线部署的关键环节都过一遍，包括数据库表设计、登录鉴权、活动报名并发控制、签到和时长审核、前端打包放进SpringBoot、常见联调问题以及答辩高频问题。我尽量不讲教科书里已有的概念，重点说哪些地方容易踩坑、为什么这么设计、怎么讲才能显得你有思考。无论你是打算直接复现，还是只参考部分模块，这套思路都适用。

1. 项目选题与整体设计思路

1.1 校园志愿者系统的需求到底在哪里

很多同学选题目时容易犯一个毛病：只看技术不看业务。志愿者管理系统听起来像个简单的“发布活动+报名”，但放到高校真实环境里，痛点其实很明显。以前学生做志愿服务，通常靠班级群接龙报名，活动结束后负责人手工记录时长，期末汇总时再翻聊天记录和纸质表，数据对不上是常事。老师想统计这个月哪个学院参与率最高、人均服务时长多少，往往要从一堆Excel里手动数，效率非常低。

所以这个系统的核心价值不是“把表单搬到网上”，而是把志愿者活动从“发布—报名—签到—记录时长—审核—统计”这条完整链路全部数字化。做毕业设计时，能把这个闭环讲清楚，比堆十个功能页面更有说服力。系统主要面向三类用户：系统管理员负责审核活动、审核时长、管理用户和公告；社团或公益项目负责人负责发起活动、现场签到；普通学生志愿者负责浏览活动、在线报名、签到、查看自己的时长和积分。这三类角色一分开，功能边界就清楚了。

我在规划模块时，建议按照“基础管理 + 业务流程 + 数据展示”三层来拆。基础管理就是用户、公告、活动类别；业务流程就是活动的发布审核、报名、签到、时长申报与审核；数据展示则是个人中心的服务时长、积分，以及管理后台的统计看板。这样的分层在写论文时也特别好用，每个模块都能对应到需求分析和系统设计章节，不用临场编。

1.2 功能模块拆解与页面规划

具体到页面，不需要做得太多，但要保证每个页面都是有用途的。我当时给一个学弟列的页面清单是这样的：

后端接口设计跟着这个页面走就行，不用额外做特别多的表。关键是每个接口都要想清楚“谁在什么条件下能用”——这就是权限设计的雏形。比如活动发布接口，普通志愿者不能调用；报名接口，只能报名已发布且未截止的活动；时长审核接口，只能管理员操作。把这些规则明确下来，后端写拦截器或者权限判断时就有依据了。

这里我还想多说一句：不要一上来就写代码。先用表格把功能列出来，哪怕每格只写一句话，后面的数据库建模和接口文档都会轻松很多。我在实际带项目时，最怕看到同学打开IDEA直接建SpringBoot项目，建完纠结取哪个包名，最后在Controller里堆了几千行代码。顺序反了，后面一定返工。

2. 技术选型与项目搭建

2.1 技术栈选择：省事但要讲得出道理

毕设选技术栈有个基本逻辑：既要能完成功能，又要能在答辩时把“为什么选它”讲明白。SpringBoot这个框架本身就是核心关键词，它最大的优势是自动配置和内置容器，几行代码就能跑起一个Web项目。相比传统的SSH、SSM那一套，省去了大量XML配置，学习成本低，资料也多，所以拿来做毕业设计非常稳妥。

版本方面，我强烈建议默认选SpringBoot 2.7.x + JDK 8的组合。不是3.x不好，而是现在网上很多教程、依赖版本都还是基于2.x，学校机房或者导师电脑上的环境未必支持JDK17。如果你非要追新，选SpringBoot 3.x也可以，但要做好心理准备：MyBatis-Plus、某些第三方工具类、Spring Cloud组件的兼容性可能会出问题，排查起来很耗时间。热搜词里有一条“SpringBoot版本太高”，说的就是这个现象——版本一高，Lombok和MyBatis-Plus的版本没跟上，报一堆莫名其妙的错。毕设求稳，别在环境上浪费一个月时间。

ORM层我推荐MyBatis-Plus。理由很实在：单表CRUD几乎不用写SQL，自带的分页插件也好用，而且它与SpringBoot整合非常顺。相比之下，Spring Data JPA虽然省操作，但很多同学对它的实体映射和派生查询不熟悉，写复杂统计反倒麻烦。MyBatis-Plus保留了自己写SQL的灵活性，复杂统计时用注解加一句自定义SQL就行。Redis在这个项目里不是必须，但如果你已经会了，可以拿它来存验证码和登录token，或者在活动详情页加缓存；如果不会，就别硬加，直接使用JVM本地缓存也一样能答辩。

前端推荐Vue3 + Vite + Element Plus。Element Plus的表格、表单、弹窗组件做管理端页面很省力。如果你对前端不熟，也可以用现成的若依框架改，但这样一来你自己对代码的掌握程度会打折，答辩时被问到细节容易露馅。我更建议自己搭一个简单的前端工程，页面不用多，但每个页面的路由、请求、状态管理你都能说清楚。下面是一个最简pom.xml里的核心依赖：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

注意：如果你选的JDK是8，MySQL驱动依赖建议写成mysql-connector-java，而不是新版本的mysql-connector-j，后者在某些SpringBoot 2.7配置下会有点小别扭。

2.2 数据库设计：五张核心表一个都不能少

数据库是整个系统的地基，也是答辩时老师最会看的东西。因为一个管理系统的业务逻辑，往往能从表关系上看出来。这里我按最小可用方案给出五张核心表，再根据你的亮点功能增加一两张扩展表。

第一张是用户表，我习惯命名为sys_user。字段包括id、username、password、real_name、student_no（学号）、phone、role、status、avatar、credit_score、create_time。password字段一定要存BCrypt加密后的密文，不能用明文也不能用MD5。role字段建议用字符串，比如ADMIN、MANAGER、STUDENT，这样权限判断一眼就能看懂。credit_score可以作为积分字段冗余在这张表里，后面统计个人总积分就不用实时聚合了。

第二张是活动表，命名为volunteer_activity。字段包括id、title、description、type、location、start_time、end_time、applicant_count（已报名人数）、max_people（人数上限）、status、publisher_id、create_time。这里的status建议用字符串枚举，比如DRAFT、PENDING、PUBLISHED、ENDED、CANCELLED。状态机一旦定好，活动发布流程就不会乱。

第三张是报名表，命名为activity_registration。字段包括id、activity_id、volunteer_id、status、sign_in_time、sign_out_time、create_time。status可以是REGISTERED、SIGNED_IN、FINISHED、CANCELLED。这张表负责承接“报名”到“签到”的整个中间过程，也是后面统计参与率的基础数据来源。

第四张是服务时长表，命名为service_hours。字段包括id、user_id、activity_id、hours、status、reviewer_id、review_time、create_time。这里status标识PENDING、APPROVED、REJECTED，即时长需要管理员审核后才计入用户总时长，这是防止学生自己虚报时长的关键设计。

第五张是公告表，命名为notice。字段包括id、title、content、publisher_id、create_time。公告虽然简单，但它是管理端信息触达的一个小亮点，页面也容易做。

表与表之间不要建物理外键，但在设计文档里要画出逻辑关系图。物理外键在大并发写入和删除时容易产生锁冲突，而且毕设项目以演示为主，逻辑关联足够。查询时使用索引字段关联即可。比如活动报名表要为activity_id和volunteer_id分别加普通索引，同时确保activity_id + volunteer_id的组合唯一，这一步很关键，可以挡住重复报名。

2.3 项目目录结构：让人一眼看出你学过工程规范

SpringBoot项目结构务必按职责分包，不要全丢在controller包下面。我常用的分包方式如下：

com.example.volunteer ├── common // 统一返回结果、异常处理、常量 ├── config // 跨域、拦截器、Jackson等配置 ├── controller // 接口层 ├── service // 业务层，接口+impl ├── mapper // MyBatis-Plus数据访问层 ├── entity // 数据库对应实体 ├── dto // 前端传参的请求/响应对象 └── utils // JWT工具、日期工具等

这样的好处是，代码量大了以后依然能很快定位问题。统一返回结果类Result也建议一开始就写好，定成类似Result.success(data)、Result.error("msg")的结构，前端只用取code、message、data三个字段。很多同学做到一半发现Controller返回类型不统一，前端联调时要写一堆判断，后期越改越乱。

还有一点，业务逻辑尽量写在Service层，Controller只做参数接收、权限校验和结果返回。比如活动报名这个动作，Controller里就几行，真正做状态判断、重复报名检查、人数扣减的逻辑全部封装在activityRegistrationService.register(activityId, userId)方法里。这样写的好处，一是代码可读性好，二是用JUnit写几个核心方法的单元测试会非常容易。毕设如果有单元测试，哪怕只有十几个用例，答辩印象分会高很多。

3. 核心功能实现：登录、报名、签到与统计

3.1 登录认证与权限控制：我为什么坚持用JWT而不是Session

登录认证是几乎所有系统都绕不开的模块，但用Session还是用JWT，很多同学只是“听别人说JWT好”就用了，答辩时一问原理就卡住。校园志愿者系统采用前后端分离架构，前端是Vue，后端是SpringBoot，两边不在同一个端口甚至可能不在同一个服务器。如果用Session，后端需要维护会话状态，前端还要处理Cookie跨域的问题。而JWT是无状态的，用户登录成功后，后端把用户id、角色等信息签名生成一段token返回给前端，前端存在localStorage里，每次请求在Header里带上Authorization就行。后端通过拦截器解析token，不用查数据库就能识别用户身份，非常适合这类接口型项目。

我在项目中习惯用jjwt生成token。举个例子：

public class JwtUtil { // 密钥字符串，实际项目中建议放到配置文件 private static final String SECRET = "your-secret-key"; public static String createToken(Long userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60)) // 2小时 .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

然后是自定义拦截器，在preHandle里获取Header中的token，解析成功后把userId放到request属性里，供后续接口使用；解析失败则直接返回401。注意注册拦截器时要排除登录、注册、静态资源路径，否则前端页面都会请求失败。这个模块做完，你就能在答辩时说清楚“无状态认证”和“会话认证”的区别，这个加分点很实在。

密码加密这块，用Spring Security中的BCryptPasswordEncoder类即可，它不像MD5那样可以直接反查彩虹表，每次加密结果都不一样，安全性足够。如果不想引入Spring Security的完整依赖，可以单独引入spring-security-crypto这个包，只使用密码加密功能，这样权限控制仍然自己写，项目也不会被Spring Security的过滤器链搞复杂。

3.2 活动发布与报名流程：状态机加并发控制

活动流程是业务中的重点。我建议用一个状态机把活动生命周期串起来：草稿(DRAFT) -> 待审核(PENDING) -> 已发布(PUBLISHED) -> 已截止(ENDED) -> 已结束(FINISHED)。负责人提交活动后，管理员在后台审核，审核通过才能被志愿者看到。这样做比“任何人创建活动后直接发布”更贴近高校的管理场景，也给了你一个“管理员审核”的模块可写。

志愿者报名时有几个条件必须同时满足：活动状态必须是已发布，当前时间必须在报名截止时间之前，活动剩余名额要大于0，而且该志愿者不能重复报名。最后一个条件光靠代码判断还不够，要在数据库层面给activity_id和volunteer_id加联合唯一索引，否则高并发下两个请求同时判断“没有报名记录”，然后都插入成功，也会产生重复数据。

对于“名额超卖”的问题，最稳妥也最简单的做法是在数据库update时做原子扣减。比如报名时先往报名表插入一条记录，然后执行：

UPDATE volunteer_activity SET applicant_count = applicant_count + 1 WHERE id = ? AND max_people > applicant_count

如果这条SQL执行后影响行数为0，说明名额已经被占完，回滚本次报名。这个写法比“先select再update”安全得多，也容易在答辩时讲清楚。我当时带学生写报名接口时，就用这个思路，代码量不大，但体现出了对并发问题的思考。

从用户视角看，前端报名按钮要处理三种状态：未报名、已报名、活动已满。前端提交后，后端会返回不同的错误信息，比如“活动已截止”“名额已满”“您已报名过该活动”，前端用Element Plus的message提醒一下就好。这个交互很简单，但能让演示过程变得很流畅。

3.3 签到、时长审核与积分体系：防止数据造假的关键设计

志愿者报名活动以后，到现场如何签到？最简单的方案是活动负责人提供一个6位签到码，志愿者在“我的活动”里输入签到码完成签到。后端记录sign_in_time和sign_out_time。签到码可以存在Redis里，也可以在活动实体里加一个字段。考虑到毕设环境不一定有Redis，我建议在活动表加一个check_code字段，活动开始时由负责人生成并展示在前端页面，志愿者输入后校验一致就完成签到。

服务时长不能由志愿者自行填写。我的做法是，活动结束后由负责人批量发起“按签到记录生成时长申请”，或者系统自动根据sign_in_time和活动end_time计算时长，写入service_hours表，status为PENDING。管理员在后台逐条审核，审核通过后才累加到用户的总时长和积分里。这里需要说明的是，时长的计算规则要提前定好：比如按小时计算，不满1小时的部分按四舍五入取整，或按实际分钟记录。如果你要算积分，可以约定每1小时计1分，具体规则在论文里写清楚就行。

积分体系是个不错的设计亮点。用户表里的credit_score字段可以通过时长审核通过后同步累加，也可以单独建一张积分明细表。我个人建议健一张credit_record表记录积分变动原因，页面展示“活动时长+1，获得积分1分”，这种细节会让评委觉得你考虑了数据溯源。积分排行榜用SELECT user_id, SUM(credit_score) FROM ... GROUP BY user_id ORDER BY ... 就能实现，前端用表格展示Top10即可。

3.4 数据看板与统计：让系统看起来更“智慧”

“智慧校园公益服务信息化系统”里的“智慧”怎么体现？如果只是普通的增删改查，答辩时老师会觉得选题不错但实现太单薄。加一个数据看板模块，就能很好地补足这一点。管理后台首页展示五个核心指标：活动总数、参与人次、总服务时长、志愿者注册数、本月新增活动数。再下面可以用ECharts画两个图表，一个展示近6个月活动发布数量趋势，一个展示学院或专业维度的参与人数分布。

统计接口的后端实现不复杂，MyBatis-Plus的QueryWrapper可以做简单聚合，复杂一点就自己写@Select注解SQL。比如查询近6个月每月活动数：

@Select("SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(*) AS cnt " + "FROM volunteer_activity " + "WHERE create_time >= #{startTime} " + "GROUP BY month ORDER BY month") List<Map<String, Object>> countLastSixMonths(@Param("startTime") LocalDateTime startTime);

返回的List

除了图表，还可以增加“服务时长明细导出Excel”功能，用EasyExcel的write方法，三个核心注解就能完成导出。这个功能特别适合在答辩演示时演示，评委看到“系统能把数据导出成报表”这个操作，通常会认为项目具备实用性。

4. 前后端联调与部署问题

4.1 Vue打包放进SpringBoot的完整流程

现在很多毕设要求“前后端分离”，但最终还是要把前端打进SpringBoot的jar里统一部署，两个服务分开跑会让学生宿舍服务器和教室演示都变得很麻烦。热搜词“vue打包放进springboot中”说明这个需求非常真实，我把步骤写完整一点。

第一步，在Vue项目根目录的vue.config.js里设置publicPath，可以是相对路径，也可以直接设为'./'，避免打包后静态资源路径错乱。第二步，执行npm run build，生成dist目录。第三步，把dist目录下的所有文件复制到SpringBoot项目的src/main/resources/static目录下。第四步，重新打包后端，运行jar，访问http://localhost:8080就能直接看到前端页面。

这里有个大坑：如果前端路由用的history模式，用户刷新页面或者直接访问某个子路由（比如/activities），由于后端没有对应的路由处理器，就会返回404。最简单的解决方案是前端路由改用hash模式，URL里会多一个#，但不会出现404。如果坚持用history模式，后端需要加一个转发配置：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { // 将非api路径转发到index.html registry.addViewController("/{path:[^\\.]*}") .setViewName("forward:/index.html"); } }

然后在Spring Boot 2.7里还要注意，如果打开了静态资源缓存，新部署的前端页面可能访问到旧版本，开发时可以在配置里暂时关闭或设置短缓存。我第一次带学生做打包部署时，忘了这个细节，导致明明替换了dist文件，浏览器还是显示老的页面，排查了很久。现在你知道了，遇到类似问题先去检查浏览器缓存和后端静态资源缓存配置。

4.2 部署到服务器：jar包、数据库和启动参数

演示用的服务器，不一定要上Docker，jar包直接部署最简单。先把后端项目用Maven打成jar包，放到服务器的指定目录。服务器提前安装好JDK8和MySQL5.7/8.0，把项目里的sql脚本导入进去。然后启动时带上生产环境参数：

nohup java -jar volunteer-system.jar --spring.profiles.active=prod &

如果product配置文件里设置了不同的端口，比如8081，访问时记得带上端口。宝塔面板是学生服务器常用工具，它可以帮你在界面上管理数据库和网站，但对SpringBoot jar包的守护进程支持比较一般。我建议自己用systemd写一个简单的服务单元文件，让项目崩溃后能自动重启，这样答辩前一天不用担心服务器挂掉。如果你不熟悉systemd，至少要用nohup + &启动，然后自己写个简单的重启脚本。

数据库初始化还要注意字符集。建库语句务必加上：

CREATE DATABASE volunteer_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

否则从Excel或者前端录入的特殊符号（比如心形符号、emoji）会保存失败，数据直接变成问号。这个小问题一旦出现，处理起来很麻烦，因为你会误以为是代码问题，实际上只是数据库字符集不对。

4.3 联调排查：接口404、跨域、时间格式

前后端联调基本是毕设的噩梦，我总结一下最常碰见的三个问题。

第一个是接口404。前端请求的baseURL写成了http://localhost:8080/api，但后端Controller的RequestMapping没有api前缀，或者写成了/api/user，导致永远访问不到。解决办法是统一约定：后端所有接口都加一个/api前缀，前端axios的baseURL就设为http://localhost:8080/api，这样最不容易错。另外还要注意Controller类上有没有加@RestController，加了以后方法返回对象才会自动JSON序列化。

第二个是跨域。浏览器里前后端分离开发时，前端端口8081访问后端8080，会产生跨域问题。后端配置一个CORS过滤器就能解决：

@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); } }

但注意，生产环境如果前端已经打包进jar包，就不会有跨域问题；只有开发环境才需要这个配置，在答辩时可以主动说明这一点，显得你理解跨域产生的条件。

第三个是时间格式。SpringBoot默认返回的LocalDateTime序列化结果可能是数组格式，前端显示一长串数字。最简单的办法是在application.yml里配置全局Jackson格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

前端就不用再单独处理时间字符串。如果是数据库里的日期字段，也要确认MySQL连接参数里配置了serverTimezone=Asia/Shanghai，否则会出现时间差8小时的问题。

5. 常见问题与答辩经验

5.1 高频答辩问题及答案要点

答辩时老师一般不会只看代码，更关心你“为什么这么设计”。我整理了五个经常被问到的角度，每个都附上回答思路。

第一个问题是“为什么选SpringBoot而不是SSH或SSM”。回答要点：SpringBoot基于Spring完善了自动配置机制，内嵌Tomcat，真正做到了“约定大于配置”，可以快速启动项目；并且生态成熟，和MyBatis-Plus、Redis等第三方库整合简单，适合快速开发和维护。

第二个问题是“系统的权限是怎么控制的”。回答要点：登录成功后生成JWT，前端将token放在Authorization请求头；后端自定义拦截器解析token并校验角色；在需要权限的接口上再根据角色做二次判断。可以补充说明没使用SpringSecurity的原因，是为了保持链路轻量、便于理解。

第三个问题是“多人同时报名同一个活动，怎么保证不超员”。回答要点：数据库层面设置联合唯一索引防止重复报名；名额扣减使用带条件的UPDATE语句（max_people > applicant_count），利用原子操作解决并发超卖；同时报名前查询活动状态防止报名已截止。这三层递进，就是标准答案。

第四个问题是“服务时长如何防止造假”。回答要点：时长不开放手动填写，只能由报名签到记录生成；签到需要有效的签到码；生成后的时长记录为待审核，经管理员审核后才会累计；数据库中有操作人ID和审核时间字段，能实现追溯。这套链路能证明数据可溯源。

第五个问题是“项目中的哪些地方体现了智慧校园场景”。回答要点：活动流程线上化、数据统计可视化、时长积分自动累计、消息公告触达，以及通过Excel导出提高信息流转效率。回答时不要只重复功能名，要强调“替代手工登记和逐级上报”这个业务价值。

5.2 避坑清单：这些坑我替你先踩了

做这个题目最典型的坑，第一是环境版本。不少同学电脑上装了JDK17，然后硬上SpringBoot2.7，结果Lombok插件版本不兼容，或者MyBatis-Plus找不到数据库。我的建议是环境统一：JDK8 + SpringBoot2.7.18 + MyBatis-Plus3.5.3，这是最稳的组合。

第二是数据库外键。很多教材教你要建物理外键，但实际开发中逻辑外键更灵活。如果某一门课要求必须体现外键，你可以在设计文档里画逻辑关系图，在答辩时解释一下。真的别建物理外键，删除活动时因为外键限制报错，调试成本很高。

第三是不要把逻辑堆在Controller里。Controller太肥，不仅代码难看，答辩时也会被老师质疑工程能力。把报名、审核、时长统计这些核心逻辑放在Service层，Controller只做参数接收和结果返回，这个习惯一定要养成。

第四是登录token过期问题。JWT过期后，前端如果只刷新页面，接口返回401，页面没有跳回登录页，用户会一头雾水。前端axios统一加一个响应拦截器，看到401状态就清掉localStorage并跳转登录页，这个小细节很加分。

第五是演示数据要提前准备好。系统开发完以后，一定要造一批真实感强的数据，比如20个用户、30个活动、几十条报名记录和时长记录。空表演示会显得项目毫无内容，提前造好数据，然后只演示“新发布一个活动”的完整流程，说服力更强。

最后再分享一点个人体会

我带学生做这个题目已经三四轮了，最大的感受是：一个毕业设计做得好不好，不在功能多少，而在于流程是否严谨、思考是否完整。校园志愿者服务管理系统表面上看只是几个增删改查，可一旦你把活动状态机、重复报名控制、时长审核链路、导出报表和数据看板都串起来，它就是一个具备真实应用价值的信息系统。如果你现在刚开始动手，建议先把数据库表和接口清单画在纸上，想清楚再写码。核心流程跑通了，再回头加那些花哨的页面。这个过程本身，就是毕设里最值钱的东西。