每年到了毕设季我都能看到一大波同学在群里问“JavaWeb毕业设计做什么题目好”。说实话高校志愿者管理系统这个题属于JavaWeb方向里既稳妥又有话可说的经典选题。它不像电商系统那么烂大街又比图书管理、学生管理这类纯CRUD多了不少业务深度报名审核、时长统计、活动流程、多角色权限这些点都能展开讲答辩时也不愁没东西聊。这个项目到底怎么从零搭起来技术栈怎么选数据库怎么设计哪些地方容易踩坑我按自己做过的思路完整拆一遍。无论你是打算直接照着做一个还是只在论文里写设计思路这篇都能拿来当参考。1. 项目整体设计与拆分思路1.1 志愿管理系统到底在解决什么问题先别急着写代码把业务想清楚比什么都重要。高校志愿者管理表面上就是“发活动、报名活动、记时长”但在实际场景里有大量细碎的问题需要系统去处理活动发布方可能是校青协、院系分队、社团活动状态要有人跟进志愿者报名之后还需要审核、签到、签退、补录时长到了期末或者评优的时候又需要按院系、按时间维度去统计时长和参与次数。另外现在很多学校对第二课堂学分有要求志愿服务时长是其中一个硬性指标这就意味着数据必须可追溯、可导出、可审核不能让一个普通学生随意改自己的时长记录。所以一个好的志愿者管理平台至少要覆盖三个角色管理员校青协负责人、活动发布者可以是管理员兼任或单独角色、普通学生志愿者。管理员管全局活动发布者管自己发起的活动学生负责报名和查看自己的服务记录。把这条主线理清楚系统的功能边界就出来了。1.2 功能模块的前置划分我在设计功能模块时喜欢先列一个“角色-功能”对照表画在纸上比记在脑子里清晰得多角色核心功能学生注册登录、浏览活动、报名/取消报名、查看审核状态、查看个人时长与积分活动发布者创建活动、管理报名名单、签到签退登记、录入时长、发布活动公告系统管理员用户管理、活动审核、时长记录审计、数据统计、系统公告、基础数据配置从这张表再往下拆就是数据库的表结构和接口设计。比如学生注册时是普通账号管理员可以设定一个“学生证号唯一”的校验逻辑同时存入院系、年级这些基础信息方便后续按学院统计时长分布。1.3 核心流程的设计要点系统中有一条最核心的业务闭环管理员发布活动 → 学生报名 → 活动方审核 → 活动开始 → 签到签退 → 时长录入 → 学生查看记录。这里的每一步都需要一个状态字段来记录活动表里要有类似status 0草稿 1报名中 2进行中 3已结束 4已取消这样的状态流转报名表里要有status 0待审核 1已通过 2已拒绝 3已取消。千万不能省掉状态字段否则后期统计和权限控制都会变得很别扭。从毕设的角度看这个业务闭环非常完整从前端页面到后端接口到数据库设计都能扣上论文里写“系统设计”和“系统实现”部分时会非常顺畅这是我建议选这个题目的核心原因。2. 技术选型与项目初始化2.1 为什么我坚持用SpringBoot 2.7.x而不是3.x搜索“springboot版本太高”的同学这两年明显变多了原因就是3.x坑了一大批人。SpringBoot 3.0之后强制要求JDK 17及以上很多同学本地环境还是JDK 8换版本又容易引发Maven依赖冲突。而且网上能找到的教程、笔记、开源代码大部分还是基于SpringBoot 2.x写的2.7.x正好是2.x的最后一个稳定版本生态最成熟遇到问题随便一搜就有答案。我在项目里选的是SpringBoot 2.7.18配合JDK 1.8这是目前最稳的毕设组合。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version1.8/java.version /properties顺便提一句如果你是用IDEA创建SpringBoot项目初始界面默认给的SpringBoot版本可能会比较高比如3.x或4.x记得手动把版本改成2.7.18再勾选依赖否则后续会出现一堆莫名其妙的编译错误。2.2 次要依赖的选择MyBatis-Plus、JWT、Knife4jMyBatis-Plus毕设阶段最友好的持久层框架。相比原生MyBatis它能少写大量XML分页查询、条件构造器都是现成的尤其适合一个人短时间开发。JWT前后端分离场景下最省事的认证方案。相比Spring Security自带的Session登录JWT是无状态的后端不需要存session前端拿到Token之后放在请求头里即可。毕设答辩时还能讲清楚“无状态认证”的概念加分。Knife4jSwagger的增强版接口文档自动生成写完接口之后直接打开浏览器看API文档联调和答辩演示都方便。Lombok减少getter/setter的样板代码这个不用多解释属于Java开发标配。Redis如果只做毕设Redis不是必须的。但我建议至少接一个验证码存储或活动热点数据的缓存哪怕用最简单的场景也能在论文里体现出你的技术广度。如果机器内存紧张可以先跳过。前端方面我建议用Vue 3 Element Plus Axios ECharts这是目前主流方案。如果你前端基础薄弱也可以直接用模板渲染方案比如Thymeleaf但我个人不太推荐因为现在高校毕设答辩越来越看重前后端分离的架构意识Vue写出来的效果也好看得多。2.3 从IDEA新建项目到跑通第一个接口这里我简单复盘一下标准步骤给还没建过项目的同学参考打开IDEA选择Spring InitializrJDK选1.8Java版本对应8。在依赖界面勾选Spring Web、MySQL Driver、Lombok。暂时不用勾MyBatis-Plus因为它的starter不在这份列表里需要手动加依赖。生成项目后在pom.xml里手动加入MyBatis-Plus和JWT相关依赖。在application.yml里配置数据源和MyBatis-Plus的日志。写一个HelloController测试启动项目访问http://localhost:8080/hello看到返回JSON即算成功。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/volunteer_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver 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这个配置里有两个容易被忽略的点。第一是serverTimezoneAsia/ShanghaiMySQL 8驱动要求必须指定时区否则连接会报错。第二是逻辑删除我建议所有业务表都加一个deleted字段用MyBatis-Plus的逻辑删除能力删数据时实际上走的是UPDATE这样能保留操作痕迹。补充一个小众但实用的技巧很多人嫌弃SpringBoot启动时那几行Banner太枯燥可以去在线Banner生成器上弄一个自定义的ASCII艺术字放在src/main/resources/banner.txt里面。这个细节虽然不影响功能但在答辩演示时会让老师觉得你项目做得很用心。3. 数据库设计把每个字段都抠明白3.1 核心表的数量和关系数据库是整个系统的地基我见过太多毕设因为表设计潦草后面越写越乱。志愿者管理系统我的建议是至少设计6张核心表sys_user用户主表包含学生端和管理员端账号。user_profile用户扩展信息表比如学号、院系、专业、年级。也可以直接合并进主表但分开写更规范。activity活动表保存活动基本信息和状态。activity_registration报名表记录学生报名行为和审核结果。service_hour_record服务时长记录表每一条记录都必须关联活动和用户。notice公告表用于管理员发布系统公告。如果想让系统更丰满还可以加activity_category活动分类、role角色表等但毕设阶段这6张表足够支撑起整个业务闭环。下面我贴几个关键表的建表SQL大家可以直接改改字段名使用CREATE TABLE activity ( id bigint(20) NOT NULL AUTO_INCREMENT, title varchar(100) NOT NULL COMMENT 活动标题, description text COMMENT 活动详情, category_id bigint(20) DEFAULT NULL COMMENT 活动分类ID, max_participants int(11) DEFAULT 50 COMMENT 报名人数上限, current_participants int(11) DEFAULT 0 COMMENT 已报名人数, service_hours_per_session decimal(5,2) DEFAULT 0.00 COMMENT 单次可获得服务时长, location varchar(200) DEFAULT NULL COMMENT 活动地点, activity_start_time datetime DEFAULT NULL, activity_end_time datetime DEFAULT NULL, registration_deadline datetime DEFAULT NULL, status tinyint(4) DEFAULT 0 COMMENT 0草稿 1报名中 2进行中 3已结束 4已取消, publisher_id bigint(20) DEFAULT NULL COMMENT 发布者ID, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4;CREATE TABLE activity_registration ( id bigint(20) NOT NULL AUTO_INCREMENT, activity_id bigint(20) NOT NULL, user_id bigint(20) NOT NULL, status tinyint(4) DEFAULT 0 COMMENT 0待审核 1已通过 2已拒绝 3已取消, audit_time datetime DEFAULT NULL COMMENT 审核时间, audit_remark varchar(255) DEFAULT NULL COMMENT 审核备注, create_time datetime DEFAULT CURRENT_TIMESTAMP, deleted tinyint(1) DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_activity_user (activity_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.2 报名表唯一索引背后的深意activity_registration里的唯一索引uk_activity_user是我特别想强调的一个点。表面上它是为了避免同一个用户重复报名同一个活动但更深层的作用是保证并发场景下的幂等性。假设页面卡了一下用户连续点了几次报名按钮如果没有这个唯一索引就非常有可能插入多条报名记录后面的签到、时长统计全部跟着乱掉。所以哪怕你在代码里做了“先查后插”的判断也一定要在数据库层面加这层保险。真正可靠的系统应该是多道防线同时起作用。3.3 字段类型与冗余字段的设计心得数据库字段设计上没有绝对的对错但有些经验是通用的。比如时间字段建议用datetime而不是timestamp因为timestamp有2038年的上限毕设虽然不会跑到那时候但这个细节被老师问到时能答出来就是加分项。再比如描述类型用text既能存长文本也不会拖慢主表查询。在冗余设计上我建议给左右两个场景留余地一是统计类的冗余比如user_profile表里可以加一个total_service_hours字段每次时长记录审核通过时同步更新这样个人主页查询时长时就不需要每次都做SUM聚合查询数据量大了以后这种优化非常关键。二是展示类的冗余比如报名列表接口里会经常用到活动标题、用户姓名如果只存了ID每次都要JOIN两张表比较繁琐可以在冗余字段里直接存一份代码会简单很多。当然冗余也要有限度不能什么字段都往里塞一般只冗余最常用的展示字段。4. 后端核心模块与实现技巧4.1 统一返回结果与全局异常处理写后端接口最忌讳的就是每个接口返回结构都不一样。你想想前端拿到数据时一会儿是{code:200, data: {...}}一会儿是{success: true, result: ...}联调阶段光是类型判断就能把人逼疯。所以项目一开始就要定义好统一返回体后面所有Controller都基于它来返回。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }全局异常处理则用RestControllerAdvice来实现把业务异常、参数校验异常、系统异常分别捕获转换成统一的Result格式返回。这样做的好处是即使某段代码忘记做异常捕获前端也不会收到一大堆英文堆栈信息体验会好很多。4.2 基于JWT的登录认证与权限控制登录模块我推荐用JWT 拦截器的方案比引入Spring Security全家桶更轻量也很容易讲清楚。具体流程是用户提交用户名密码后端校验通过后生成一个TokenToken里可以装userId、username、role这些信息然后返回给前端。之后前端每次请求都在Authorization请求头里带上这个Token后端通过拦截器解析Token拿到当前登录用户的信息。Token生成我使用io.jsonwebtoken库Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; public String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }权限控制上我建议先做一个自定义注解RequireRole然后在拦截器中读取注解里的角色值和JWT里解析出来的角色做比对。比如活动发布接口标了RequireRole(ADMIN)那普通学生就没法调用。这样比在每个Controller方法里手动if判断要优雅得多答辩时也更容易展示你对AOP思想的理解。注意JWT的密钥不要硬编码在代码里要放到application.yml中答辩时老师问到配置分离也能有话讲。另外Token过期时间不要设置太长一般24小时就够配合前端在401时跳转登录页即可。4.3 活动报名与人数控制并发和事务的取舍活动报名是系统里最容易出bug的地方。假设一个活动报名上限是100人第100和第101个人同时点击报名如果你的代码是先查出当前人数再加1写回两个请求都查到99都认为没满结果就有101个人报名成功了。这就是经典的并发问题。解决方式有几种一种是给活动表加一个版本号用乐观锁一种是直接使用数据库的原子更新语句。SpringBoot MyBatis-Plus环境下我推荐用UpdateWrapper做原子更新Override Transactional(rollbackFor Exception.class) public ResultVoid registerActivity(RegisterRequest request) { Long activityId request.getActivityId(); Long userId UserContext.getUserId(); // 1. 查询活动信息 Activity activity activityMapper.selectById(activityId); if (activity null) { throw new BizException(活动不存在); } if (activity.getStatus() ! 1) { throw new BizException(当前活动不在报名时间内); } // 2. 原子更新已报名人数防止并发超卖 UpdateWrapperActivity updateWrapper new UpdateWrapper(); updateWrapper.eq(id, activityId) .eq(current_participants, activity.getCurrentParticipants()) .lt(current_participants, activity.getMaxParticipants()) .setSql(current_participants current_participants 1); int update activityMapper.update(null, updateWrapper); if (update 0) { throw new BizException(报名人数已满请报名其他活动); } // 3. 写入报名记录利用唯一索引兜底 ActivityRegistration registration new ActivityRegistration(); registration.setActivityId(activityId); registration.setUserId(userId); registration.setStatus(0); try { registrationMapper.insert(registration); } catch (DuplicateKeyException e) { throw new BizException(您已报名过该活动请勿重复报名); } return Result.success(null); }这段代码里有几个关键点。第一是整个方法加了Transactional确保报名人数1和插入报名记录要么都成功要么都失败。第二是更新语句里带上了current_participants的相等条件这是乐观锁的思路如果两个请求同时来只会有一个更新成功另一个affected rows为0就会抛“人数已满”异常。第三是插入报名记录时依靠数据库唯一索引捕获重复报名避免代码层面先查后插的竞态窗口。这三点结合基本可以把并发下的常见问题全部堵死。时长录入也是同样的思路。活动结束后负责人给志愿者录时长每一条service_hour_record记录都需要包含活动ID、用户ID、时长数值、录入人ID。并且要做一个限制同一个活动同一个人只能有一条有效时长记录靠唯一索引保证。4.4 定时任务让活动状态自动流转活动状态不能一直靠人工改。比如报名截止时间到了状态应该自动从“报名中”变成“进行中”活动结束时间过了应该自动变成“已结束”。这种逻辑可以用SpringBoot自带的Scheduled定时任务实现非常简单Component Slf4j public class ActivityStatusTask { Resource private ActivityMapper activityMapper; Scheduled(cron 0 */5 * * * ?) public void autoUpdateActivityStatus() { // 自动开始到了开始时间且状态为“报名中”的活动 LocalDateTime now LocalDateTime.now(); UpdateWrapperActivity startWrapper new UpdateWrapper(); startWrapper.eq(status, 1) .le(activity_start_time, now) .set(status, 2); activityMapper.update(null, startWrapper); // 自动结束过了结束时间且状态为“进行中”的活动 UpdateWrapperActivity endWrapper new UpdateWrapper(); endWrapper.eq(status, 2) .le(activity_end_time, now) .set(status, 3); activityMapper.update(null, endWrapper); } }注意启动类上要加EnableScheduling注解否则定时任务不会生效。这段逻辑可以放到“系统工具类”或者“任务调度包”下代码量不多但对系统的完整性提升是肉眼可见的。4.5 文件上传活动图片与头像存储如果系统允许发布活动时上传封面图、用户上传头像就需要一个文件上传接口。我的建议是不要把文件保存进数据库字段而是存在服务器的某个目录里数据库只保存访问路径。实现方式也很直接配置一个虚拟路径映射把http://localhost:8080/files/**映射到本机的/usr/local/volunteer/files/目录上传接口用MultipartFile接收文件然后用UUID生成新文件名避免重名覆盖。存储路径的配置注意放在application.yml里不要硬编码file: upload-path: /usr/local/volunteer/files/ access-path: /files/**跨域问题也要提前处理。前后端分离开发时前端在http://localhost:5173后端在http://localhost:8080两者端口不同必然会有跨域请求。最简单的方案是写一个WebMvcConfigurer配置类添加跨域映射规则允许所有来源、所有请求头、所有方法。如果后期用Nginx部署了还可以在Nginx层面做反向代理把/api转发给后端服务这样前端请求的都是同域的/api路径不跨域。5. 前端页面设计与数据可视化5.1 页面结构和路由划分前端用Vue3的话建议页面结构分成三块登录注册页、学生端主界面、管理端主界面。路由上可以用vue-router通过动态路由或登录后的角色判断来区分前后台。管理端的页面可以这样划分仪表盘展示活动总数、志愿者人数、服务总时长、待审核报名等核心指标配合ECharts图表展示近一月活动数量趋势。活动管理活动列表、创建活动、编辑活动、下架活动。报名审核待审核列表、通过/拒绝操作。时长管理时长记录列表、录入、修正。用户管理学生列表、启用/禁用账号、重置密码。公告管理发布公告、公告列表。学生端则简单很多首页看活动列表点进详情看活动内容、剩余名额、截止时间个人中心看已报名的活动、审核状态、自己的服务时长记录。5.2 Axios封装与Token自动携带前端交互的核心是Axios建议在项目里封装一个统一的请求工具。比如在请求拦截器里统一加上JWT Tokenimport axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.response?.data?.message || 网络异常) return Promise.reject(error) } ) export default request这段代码有一个设计细节值得注意返回给组件的是res而不是res.data。这样业务组件里写const { data } await request.get(/activity/list)就够了不需要每次都手动剥一层code和message实际写页面时会清爽很多。5.3 数据可视化用ECharts汇报成果仪表盘页面是答辩的亮点环节建议用ECharts展示3到4个图表饼图展示志愿者院系分布柱状图展示每月新增活动数折线图展示每月累计服务时长。ECharts的Vue封装可以用vue-echarts也可以直接用原生ECharts在onMounted里初始化图表实例。数据接口方面后端写一个统计Controller用SQL聚合查询返回结果。比如按院系统计志愿者人数的SQL可以这样写Override public ListMapString, Object countByCollege() { return userMapper.selectMaps(new QueryWrapperUserProfile() .select(college, COUNT(*) as count) .groupBy(college)); }MyBatis-Plus的selectMaps返回的结果是ListMapString, Object前端拿到直接渲染。这里有个小坑提醒selectMaps在MySQL里别名会变成map的key所以SQL里最好写清楚COUNT(*) as count否则返回的key可能跟你预期不一致。5.4 前后端联调时的注意事项联调阶段最容易出问题的不是业务逻辑而是一些基础配置。比如IDEA中后端启动在8080端口Vue3默认是5173端口这时需要在vite.config.js里配置代理否则Ajax请求会404export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这样前端请求/api/activity/list会被代理到http://localhost:8080/activity/list前端代码里不需要写死后端地址。如果你没有配置代理前端代码里直接写死http://localhost:8080也可以跑通但配置了代理后上线部署时只需要改Nginx不用改前端代码灵活性会高很多。6. 常见问题排查与答辩重点准备6.1 运行期最常见的几个报错从我的经验来看毕设项目跑不起来90%是环境问题而不是代码问题。这里整理一份高频踩坑清单基本上涵盖了大部分队伍遇到的问题报错现象根因解决方案Access denied for user rootlocalhostMySQL密码错误或账号无权限检查application.yml中的数据库密码确认端口3306Unknown database volunteer_system数据库不存在先在MySQL里执行create database volunteer_systemFailed to configure a DataSourceapplication.yml中数据源配置缺失检查配置文件是否被IDEA识别为资源文件java.sql.SQLException: The server time zone value未指定时区在JDBC URL最后加serverTimezoneAsia/ShanghaiInvalid bound statement (not found)Mapper接口与XML不匹配检查Mapper接口包路径和MapperScan是否一致Port 8080 was already in use端口被占用用netstat -ano查PID杀掉进程或改server.portJWT解析报JWT signature does not match密钥不一致确认所有服务实例使用相同的jwt.secret6.2 数据库字段和SQL引发的隐藏问题还有一种报错排查起来更头疼就是接口能通但数据不对。比如前端显示活动列表正常但报错申请时提示“已满”查了下数据库明明只有10人报名活动上限写的是50。这种问题多半是current_participants字段没有正确维护比如手动往报名表插了数据但没有同步更新活动表的字段。解决思路是不要直接改数据库所有报名和取消报名都走后台Service保证字段一致性。另一个常见问题是时间差八小时。MySQL连接中如果不设置serverTimezoneAsia/Shanghai默认会使用服务器时区如果服务器是UTC存进去的时间就会差8小时。这个在前面配置文件里已经加了但如果你有用到Jackson序列化时间还需要在application.yml里配置统一的日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT86.3 答辩前必须吃透的几个问题很多同学项目做完了但答辩时被老师一问就卡壳。我根据经验整理几个高频问题大家提前把答案组织好为什么选SpringBoot答SpringBoot简化了Spring的配置流程内置Tomcat自动装配机制大大提升开发效率。同时它和Spring生态天然兼容适合快速开发和迭代。MyBatis-Plus和MyBatis的区别答MyBatis-Plus是MyBatis的增强工具内置通用Mapper和通用Service单表CRUD不需要写SQL复杂查询还能用条件构造器。它只做增强不做侵入可以无缝兼容原生MyBatis。项目里的事务是怎么控制的答主要是在Service层加Transactional注解比如报名、时长录入这些写操作都要求原子性。同时利用乐观锁控制并发避免超卖。JWT和Session的区别是什么答Session是服务端存储有状态JWT是客户端存储无状态。JWT把用户信息加密编码在Token里服务端只需要验签不需要保存用户状态更适合前后端分离和分布式场景。数据量大了怎么办答从几个维度考虑数据库建索引、分页查询热点数据缓存到Redis活动列表可以做读写分离静态资源用CDN。毕设阶段讲清楚前两点就足够了。6.4 让演示效果翻倍的三个小细节最后说几个能让答辩演示眼前一亮的小细节。第一提前准备一份真实的演示数据最好有200个用户、50条活动记录、几百条时长记录这样图表页面渲染出来的效果特别饱满。第二演示时先把系统的核心业务闭环跑一遍从登录到报名到审核到录入时长到查看统计这个流程走完老师对系统的整体性就有了直观感受。第三准备一段不超过3分钟的录屏备份万一现场网络或电脑出问题还能用录屏完成演示避免尴尬。我个人在实际操作中的体会是这个项目最花时间的往往不是写代码而是理清楚业务边界和状态流转。很多同学一上来就撸代码写着写着发现报名状态要么多要么少页面和接口对不上返工成本很高。如果动手前老老实实把角色表、状态图、接口清单列出来后面开发会顺利很多。另外做毕设不要求功能堆得多天花乱坠把核心业务闭环做扎实比做一堆半成品功能要强得多。系统完成后建议自己把所有角色各注册一个账号完整跑几遍站在使用者角度走一遍流程很多体验问题一眼就能看出来。