Spring Boot大创管理系统实战：三角色审批流与二次开发指南

简介：这份资源是面向计算机专业毕业生的大创管理系统毕业论文文档，基于Spring Boot与SSM框架开发，适合正在准备毕业设计或课程设计的学生参考。文档完整呈现了从摘要、背景意义、需求分析、可行性分析到数据库设计、数据流图、详细设计、系统测试与总结的论文结构，并围绕学生、指导老师、院系管理员三类角色展开项目申报、中检、结项、评审等业务流程，技术部分涵盖Spring Boot自动配置、SpringMVC与MyBatis整合及MySQL数据存储。压缩包共1个doc文件，约2.57MB，内容为可直接查阅的论文正文与系统截图。已有134人学习，读者可借此了解大创管理系统的完整开发思路、论文写作框架与功能模块划分，为选题、撰写和答辩提供参考。

1. 大创管理系统：从论文文档到可运行项目的完整拆解

每年三四月份，高校里管大创项目的老师最头疼的一件事，就是收表。学生交上来的申报书是 Word，中检报告是 PDF，结项材料又混着压缩包，评审专家的打分表还散在几个邮箱里。一个院系几十个项目，光是把材料对齐、把状态更新到 Excel，就能耗掉整整两周。这份毕业论文配套的源码，做的就是把这套流程搬进浏览器里的事——学生在线申报，指导老师在线审核，院系管理员统一调度，项目从申报、中检到结项、评审，每一步都有状态可查。技术栈是 Spring Boot + SSM + MySQL 的经典 B/S 组合，适合拿来做课程设计复现、毕业设计二次开发，或者当成一个中小型审批流系统的骨架来改。下面我按「它是什么 → 怎么跑起来 → 核心代码怎么写的 → 怎么改成自己的」这个顺序，把这份资源拆开讲清楚。

2. 系统定位与技术选型：三角色审批流为什么落在 Spring Boot 上

2.1 三个角色撑起的业务闭环

这套系统的业务模型不复杂，但角色划分很清晰，这也是它适合做教学项目的原因。学生、指导老师、院系管理员三方，各自的功能边界在论文里写得很明确：

从这张表能看出来，系统的本质是一个带状态机的审批流：项目申报后进入待审，指导老师审完流转到院系，中检和结项各走一轮，最后评审方案把打分规则固化下来。论文里提到的「优秀项目」其实是结项后的一个标记位，管理员可以把评分高的项目挂到首页展示。这种设计在真实的大创管理场景里很常见，因为学校确实需要把优秀案例沉淀下来给下一届看。

2.2 为什么是 Spring Boot + SSM 而不是别的

论文摘要里写的是「采用 SSM 框架，MYSQL 数据库设计开发」，正文又提到 Spring Boot 作为核心框架。这两者不矛盾——SSM 是 Spring + SpringMVC + MyBatis 的经典组合，Spring Boot 是在它上面做自动配置和起步依赖的封装。对于这种规模的系统，选这套栈有几个现实理由：

第一，MyBatis 的 XML 映射对毕业设计场景很友好。大创系统的表结构相对固定，字段名和业务含义一一对应，用 MyBatis 写 SQL 比 JPA 的自动生成更可控，查出来的字段直接映射到实体类，调试时看 SQL 日志一目了然。

第二，SpringMVC 的注解式 Controller 让权限拦截好做。三个角色的接口前缀可以分开，比如/student/**、/teacher/**、/admin/**，配一个拦截器按 session 里的角色做校验，比 Spring Security 轻量得多，也更容易在论文里讲清楚。

第三，MySQL 在这个数据量级下完全够用。一个院系一年几十到上百个项目，几张主表加几张关联表，单机 MySQL 跑起来毫无压力，部署成本也低。

提示：论文里同时出现了「SSM 框架」和「Spring Boot」两种说法，实际代码大概率是 Spring Boot 项目里集成了 MyBatis，而不是传统 XML 配置的 SSM。跑之前先看pom.xml里有没有spring-boot-starter-web和mybatis-spring-boot-starter，有的话就按 Spring Boot 的方式启动。

2.3 技术栈清单与版本预期

论文没有给出完整的依赖版本，但按这类项目的常见做法，pom.xml里一般会有这些：

<!-- 常见依赖组合，版本以实际 pom 为准 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.x</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> </dependency>

PageHelper 这类分页插件在管理后台里几乎是标配，因为项目列表、评审记录都是分页展示的。前端大概率是 JSP 或者 Thymeleaf 模板，论文里提到「JSP 技术是将 JAVA 语言作为脚本语言的」，说明视图层用的是服务端渲染，而不是前后端分离。这一点对二次开发影响很大：改页面要动模板文件，不是改 Vue 组件。

3. 跑起来：环境准备、数据库导入与启动验证

3.1 环境清单与版本对齐

这类 Spring Boot 项目的环境要求不苛刻，但版本对不齐会直接启动失败。按论文里「JDK1.8 版本」的说法，准备下面这套组合最稳：

• JDK 1.8（不要用 17，老项目的反射和依赖容易出问题）
• Maven 3.6+
• MySQL 5.7 或 8.0（8.0 要注意驱动类名和时区参数）
• IDEA 或 Eclipse（IDEA 对 Spring Boot 支持更好）
• 浏览器（Chrome 即可，B/S 架构不需要装客户端）

数据库连接配置一般在src/main/resources/application.yml或application.properties里。常见写法是：

spring: datasource: url: jdbc:mysql://localhost:3306/dachuang?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.dachuang.entity

serverTimezone这个参数在 MySQL 8.0 下必须加，否则启动时报时区错误。mapper-locations指向 XML 映射文件目录，如果项目用的是注解式 Mapper，这一行可以不要。type-aliases-package让 XML 里可以直接写实体类简名，省掉全限定名。

3.2 数据库导入的实操步骤

论文第 4.3 节给了数据库设计表，包括大创资讯表、评审方案表等，字段类型和注释都有。源码包里通常会带一个.sql文件，导入流程是：

# 1. 登录 MySQL mysql -u root -p # 2. 创建数据库（库名以 sql 文件里的为准） CREATE DATABASE dachuang DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 3. 导入表结构和初始数据 USE dachuang; SOURCE /path/to/dachuang.sql;

导入后先SHOW TABLES;确认表数量，再随便SELECT * FROM 大创资讯表 LIMIT 5;看看有没有初始数据。如果 sql 文件里没有建库语句，就手动建库再导入；如果导入报外键错误，先SET FOREIGN_KEY_CHECKS=0;再导，导完记得改回来。

注意：论文里的表名可能是中文注释、英文表名的混合形式，导入前用文本编辑器打开 sql 文件扫一眼，确认表名和实体类里的@TableName或 XML 里的resultMap对得上，对不上就是版本不匹配，后面查数据会全是空。

3.3 启动与登录验证

数据库就绪后，在 IDEA 里找到带@SpringBootApplication的主类，右键 Run。控制台出现Started XxxApplication in x seconds就算起来了，默认端口一般是 8080。浏览器访问http://localhost:8080，应该能看到登录页。

登录账号通常在 sql 文件的用户表里有初始数据，或者论文截图里会标注。三个角色的入口可能是同一个登录页按角色跳转，也可能是分开的登录地址。验证顺序建议是：先用管理员账号登录，看菜单是否完整；再退出用学生账号登录，确认看不到管理菜单；最后用指导老师账号走一遍审核列表。这一步能快速判断权限拦截有没有生效。

如果启动报Table 'xxx' doesn't exist，说明库名或表名对不上；如果登录后 404，检查 Controller 的@RequestMapping路径和模板文件位置是否一致；如果页面样式全丢，看静态资源目录static下的 css/js 有没有被拦截器挡住。

4. 核心模块拆解：从项目申报到评审的代码链路

4.1 项目申报的 Controller 与状态字段

项目申报是整个流程的起点，也是最能体现「角色 + 状态」设计的模块。按论文的功能描述，学生提交申报后，记录进入待审核状态，指导老师和管理员分别能看到自己权限范围内的待办。一个典型的 Controller 写法是：

@RestController @RequestMapping("/student/project") public class ProjectApplyController { @Autowired private ProjectInfoService projectInfoService; // 学生提交项目申报 @PostMapping("/apply") public Result apply(@RequestBody ProjectInfo projectInfo, HttpSession session) { // 从 session 取当前登录学生，防止前端伪造 userId User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null || !"student".equals(loginUser.getRole())) { return Result.error("未登录或无权限"); } projectInfo.setStudentId(loginUser.getId()); // 初始状态设为待审核，具体枚举值以项目为准 projectInfo.setStatus("待审核"); projectInfo.setCreateTime(new Date()); projectInfoService.save(projectInfo); return Result.success("申报成功"); } // 学生查看自己的申报列表 @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size, HttpSession session) { User loginUser = (User) session.getAttribute("loginUser"); PageHelper.startPage(page, size); List<ProjectInfo> list = projectInfoService.listByStudentId(loginUser.getId()); return Result.success(new PageInfo<>(list)); } }

这段代码有几个关键点。session.getAttribute("loginUser")是权限校验的兜底，不能只信前端传的studentId，否则改个请求参数就能替别人申报。status字段是整条审批链的核心，申报时置为「待审核」，指导老师审核后改成「已通过」或「已驳回」，中检和结项各自维护自己的状态字段，不要混用。PageHelper.startPage必须紧跟在查询之前，中间不能插别的数据库操作，否则分页会串。

参数说明：page和size是分页参数，默认第一页每页十条；ProjectInfo实体里应该包含项目名称、项目类型、负责人、成员、经费预算、预期成果等字段，对应论文 4.3.1 里评审方案实体属性图列出的那些属性。

4.2 指导老师审核与状态流转

审核动作本质是一次带条件的更新，难点在于「只能审自己名下的项目」和「状态不能倒退」。常见实现是：

@Service public class ProjectAuditService { @Autowired private ProjectInfoMapper projectInfoMapper; @Transactional public Result audit(Long projectId, String auditResult, String remark, Long teacherId) { ProjectInfo project = projectInfoMapper.selectById(projectId); if (project == null) { return Result.error("项目不存在"); } // 只有待审核状态才能被审核，防止重复提交 if (!"待审核".equals(project.getStatus())) { return Result.error("当前状态不可审核"); } // 校验该项目是否分配给当前指导老师 if (!teacherId.equals(project.getTeacherId())) { return Result.error("无权审核该项目"); } project.setStatus(auditResult); // 已通过 / 已驳回 project.setAuditRemark(remark); project.setAuditTime(new Date()); projectInfoMapper.updateById(project); return Result.success("审核完成"); } }

@Transactional在这里是必要的，因为真实项目里审核通过后可能还要写一条审核日志、更新统计表，多个写操作要在一个事务里。状态判断放在更新之前，是防止两个老师同时点审核导致状态被覆盖。teacherId从 session 取，不要从请求体取，这是权限校验的基本盘。

论文里提到指导老师还有「项目类型管理」和「评审方案管理」，这两块本质是字典表和规则表的 CRUD，代码结构和上面类似，只是没有状态流转，改的时候注意类型被项目引用后不能直接删，要做逻辑删除或者先校验引用数。

4.3 评审方案与专家评审的数据结构

评审方案是这套系统里比较有特色的模块。论文 4.3.1 的实体属性图列出了评审方案的字段：标题、创新点、前期准备、实施方案、预期成果、经费预算、成员素质、图片、创建时间。这说明评审方案不是简单的打分表，而是一套评分维度的模板，专家按这些维度给项目打分。

对应的表设计大致是两张：一张review_plan存方案本身，一张review_record存专家对某个项目的打分记录，通过plan_id和project_id关联。专家评审管理的代码重点是「一个专家只能评一次」和「分数汇总」：

// 专家提交评审打分 @PostMapping("/expert/review") public Result submitReview(@RequestBody ReviewRecord record, HttpSession session) { User expert = (User) session.getAttribute("loginUser"); // 唯一性校验：同一专家对同一项目同一方案只能提交一次 int count = reviewRecordMapper.countByExpertAndProject( expert.getId(), record.getProjectId(), record.getPlanId()); if (count > 0) { return Result.error("您已提交过评审，不能重复打分"); } record.setExpertId(expert.getId()); record.setReviewTime(new Date()); reviewRecordMapper.insert(record); return Result.success("评审提交成功"); }

分数汇总一般放在管理员端，按项目GROUP BY求平均分，再按分数排序决定优秀项目。这里容易翻车的地方是分数字段用了varchar存，排序时变成字符串比较，10 分排在 9 分前面。建表时分数一定要用decimal或int。

4.4 数据库表与实体映射的对应关系

论文 4.3.2 给了大创资讯表和评审方案表的字段定义，包括id、addtime、title、introduction、picture、content这些。实体类映射时要注意addtime是timestamp类型且默认CURRENT_TIMESTAMP，插入时可以不传，让数据库自动填。MyBatis 的 XML 里对应写：

<insert id="insertNews" parameterType="News"> INSERT INTO news (title, introduction, picture, content) VALUES (#{title}, #{introduction}, #{picture}, #{content}) </insert>

addtime不写进 insert 语句，靠数据库默认值，这样避免 Java 端时间格式和数据库时区不一致的问题。查询时如果要按时间倒序，ORDER BY addtime DESC即可。图片字段存的是路径字符串，文件上传逻辑单独写在FileController里，存到本地磁盘或static/upload目录，数据库只存相对路径。

5. 避坑与排查：启动、权限、分页和中文乱码的踩坑记录

5.1 启动报数据源错误

现象：控制台抛Failed to configure a DataSource: 'url' attribute is not specified。原因通常是application.yml缩进错了，或者配置写在了application.properties里但文件名拼错。解决：检查spring.datasource.url是否在spring:下一级，YAML 对缩进敏感，两个空格不能省；确认配置文件在src/main/resources根目录下。

5.2 登录后菜单全显示或全不显示

现象：学生登录后能看到管理员菜单，或者管理员登录后菜单是空的。原因多半是前端模板里用角色字段做判断时，字段值大小写或中英文对不上，比如数据库存的是「学生」，模板里判断的是student。解决：统一角色标识，建议数据库存英文枚举（student/teacher/admin），页面展示时再转中文；拦截器和模板判断用同一套常量。

5.3 分页查询第二页数据重复

现象：列表翻到第二页，数据和第一页有重复。原因一般是PageHelper.startPage之后又执行了别的查询，或者ORDER BY字段不唯一导致分页边界不稳定。解决：startPage紧贴目标查询；排序字段加上主键做第二排序键，比如ORDER BY create_time DESC, id DESC。

5.4 中文提交后变问号

现象：表单里输入中文，保存到数据库变成???。原因有三层：数据库字符集不是utf8mb4、连接 URL 没带characterEncoding=utf8、或者 Tomcat 的server.tomcat.uri-encoding没配。解决：建库时指定utf8mb4，JDBC URL 加编码参数，application.yml里加server.tomcat.uri-encoding: UTF-8，三处对齐基本能解决。

5.5 文件上传后访问 404

现象：图片上传成功，数据库路径也有，但页面显示裂图。原因通常是上传目录不在静态资源映射范围内，或者路径拼接时多了/少了斜杠。解决：配置WebMvcConfigurer把上传目录映射成/upload/**，数据库存/upload/xxx.jpg这种以斜杠开头的相对路径，前端直接用这个路径访问。

6. 二次开发：把大创系统改成你自己的审批流

拿到这份源码，最值钱的不是它现在能管大创项目，而是它把「多角色 + 多状态 + 审核流转」这套骨架搭好了。改成别的审批场景，改动量比从零写小得多。我一般会按下面这个顺序动手。

第一步，换业务实体。把ProjectInfo改成你要管的对象，比如设备借用申请、请假单、报销单。实体字段跟着换，但status、createTime、applicantId、auditorId这四个字段保留，它们是流转的骨架。对应的 Mapper XML 里的列名同步改，别漏了resultMap。

第二步，改状态枚举。大创系统的状态是「待审核 → 已通过/已驳回」，中检和结项各有一套。如果你的流程是三级审批，就在状态里加「一级通过」「二级通过」，审核 Service 里的状态判断从if (!"待审核".equals(...))改成按当前节点判断。建议把状态值抽成枚举类，别在代码里散落字符串。

第三步，调权限拦截。三个角色的接口前缀分开是最省事的做法，改的时候把拦截器的路径规则和角色映射表一起改。如果新系统角色数量变了，session 里存的角色字段要同步调整，前端菜单的显示条件也要跟着改，这两处最容易漏。

第四步，验证方法。改完不要直接上页面点，先写一个简单的接口测试：用学生角色提交一条记录，查数据库确认状态是初始值；用审核角色调审核接口，确认状态变了且审核时间有值；再用学生角色查列表，确认能看到最新状态。这三步走通，流转逻辑基本就对了。

有个血泪教训：我第一次改这类项目时，直接在前端模板里把「大创」字样全局替换成新业务名，结果把数据库表名注释和几个接口路径也替换了，启动直接报错。从那以后我每次做这种改造，都先把git初始化提交一版原始代码，改的时候按「实体 → Mapper → Service → Controller → 模板」的顺序一层层来，每层改完跑一次启动，不一次性全改。这样出问题能立刻定位到是哪一层，不用对着几百个文件猜。希望这套拆解能帮你把这份源码顺利跑起来，也改成自己真正想要的样子。

本文还有配套的精品资源，点击获取