企业官网建设流程全解析

1. 毕设开题先想明白：大创管理系统到底在管什么

如果你正在为Java Web方向的毕业设计发愁，那么“大学生创新创业训练项目管理系统”这个题目，大概率已经在你的备选清单里出现过。这个被无数高校当成标配业务场景的系统，从题目复杂度、业务完整度、答辩可讲度三个维度来看，确实是Java Web毕设里性价比很高的一个选择——尤其搭配SpringBoot+Vue这套前后端分离打法。网上流传的完整项目源码、SQL脚本、接口文档并不少，但真正能让你跑起来并且讲清楚的项目，其实很少。

在接触大量类似的毕设项目后，我发现一个普遍问题：很多同学拿到源码第一件事就是启动项目，然后把页面截图放进论文，最后答辩被问“你这个项目的核心业务流程是什么”“评审环节怎么设计的”就卡住了。原因很简单——多数人根本没有把这个系统当成一个业务系统去理解。

1.1 五种角色和一条完整的大创业务链

大学生创新创业训练计划，在高校里通常叫“大创”。它的业务链路大致是这个样子的：学校发布申报通知，学生组建团队填写申报书，指导老师审核并给出意见，学院管理员做资格初审，然后进入专家评审环节，评审通过后正式立项。立项之后不是结束，项目要执行，执行期间有中期检查，结项时要提交成果材料、经费使用情况，最后是结题验收。结题之后还可能有优秀项目推优、成果登记等后续动作。

这条链路上涉及的角色至少有五种：学生、指导教师、学院管理员、校级管理员、评审专家。不同角色看到的界面不同、操作的权限不同、关心的数据也不同。

我在给你整理项目文档的时候，特意把“业务角色—操作权限—状态变化”做成了一张对应表，这张表我认为比任何一张页面截图都重要，因为它就是整个系统的需求骨架：

项目状态的流转是这套系统的灵魂。从“草稿”到“已结题”，中间每一步操作都在改变状态，而状态的改变又会决定哪些按钮对当前用户可见、哪些操作允许执行。

1.2 为什么说它不是单纯的CRUD系统

我发现很多人把这类系统理解为“数据增删改查”，这种理解会直接导致代码设计上的灾难。真正的创训系统，一不会让你随便改数据——某个项目一旦提交立项，学生的编辑按钮就该消失；二不允许你越权操作——学生不能查看评审专家的评分明细；三要求所有操作留痕——结题审核必须记录审核人、审核时间和审核意见。

这套系统的本质是多角色、带审批流、强状态机约束的流程管理系统。你数据库里存的不只是“项目表里多了一行记录”，而是一个项目从申报到结题全生命周期的状态快照。设计的时候，代码结构围绕“角色—状态—操作”来组织，远比你围着“增删改查”来组织要清晰得多。

2. 技术选型与工程结构：为什么这套组合依然是首选

既然题目是SpringBoot+Vue，我先把这个选型逻辑说透。技术栈不是越新越好，也不是越复杂越好，对毕设来说，稳定成熟、资料多、能用自己的话讲明白才是最核心的评判标准。

2.1 后端：SpringBoot 2.7 + MyBatis Plus + MySQL

SpringBoot这个框架本身不用多说，它省掉了一堆繁琐的XML配置，内置Tomcat，打成jar包就能跑。项目里我建议用SpringBoot 2.7.x这个版本，原因很简单：网上能查到的教程绝大多数基于2.x，遇到问题时随便一搜都是现成答案。如果你非得用Spring Boot 3.x，那你得踩一遍 Jakarta EE 命名空间变更、Spring Security 6 配置变化之类的坑，网上老资料很多都对不上号，平白无故给自己加难度。

持久层选择MyBatis Plus而不是原生MyBatis，理由也很实在：单表CRUD完全不用手写SQL，BaseMapper自带selectById、insert、updateById这些方法，开发速度快很多。更重要的是分页插件、逻辑删除、自动填充这些功能都是现成的，论文里也可以写一句“通过MyBatis Plus减少了大量重复SQL编写”，这也是加分项。

数据库用MySQL 5.7或8.0都可以，SQL脚本文件我建议同时准备一份5.7兼容版本，因为部分高校机房的老版本MySQL可能不支持utf8mb4_0900_ai_ci这类字符集排序规则。这是很现实的问题，别再问我为什么明明脚本一样，导入到机房电脑上就报错。

2.2 前端：Vue 2.6 + Element UI + Axios

前端选Vue 2而不是Vue 3，可能很多人不理解。我的观点是这样的：如果你对Vue 3的Composition API烂熟于心，用Vue 3写当然没问题；但对于大多数Java方向的毕设同学，Vue 2的Options API配合Element UI组件库，上手曲线最平缓。Element UI提供的表格、表单、对话框、分页、上传组件，几乎就是为管理系统量身定做的。Vue 3对应的Element Plus当然也成熟了，但你搜到的很多教程、组件示例、踩坑文章都是Vue 2时代的，直接抄作业的难度完全不是一个量级。

工程化方面，用Vue CLI 5.x创建项目，配合Vue Router做路由控制，Vuex或Pinia存登录状态和用户信息，Axios封装请求拦截器。前端和后端完全分离，前端通过HTTP接口访问后端API。

2.3 项目目录结构长什么样

拿到手的一套完整源码，后端和前端应该是两个独立目录。我建议这样组织：

project-system/ ├── backend/ # SpringBoot后端工程 │ ├── src/main/java/com/example/project/ │ │ ├── controller/ # 控制层，只做参数接收和结果返回 │ │ ├── service/ # 业务逻辑层，核心流程都在这里 │ │ ├── mapper/ # MyBatis Plus的Mapper接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── dto/ # 前端传入参数对象 │ │ ├── vo/ # 返回给前端的数据对象 │ │ ├── config/ # 拦截器、跨域、Swagger等配置 │ │ ├── common/ # 统一返回结果、异常处理 │ │ └── utils/ # JWT、文件上传等工具类 │ └── src/main/resources/ │ ├── mapper/ # XML文件（复杂SQL放这里） │ └── application.yml ├── frontend/ # Vue前端工程 │ ├── src/ │ │ ├── api/ # 按模块拆分的接口定义 │ │ ├── views/ # 页面组件 │ │ ├── components/ # 公共组件 │ │ ├── router/ # 路由配置 │ │ ├── store/ # 状态管理 │ │ └── utils/ # axios封装、token处理 ├── sql/ # SQL脚本 └── doc/ # 接口文档、数据库设计说明

后端三层架构——Controller负责接入，Service负责业务逻辑，Mapper负责数据访问——这是最标准的SpringBoot组织方式。有一个细节特别提醒：不要把业务逻辑写在Controller里。答辩老师经常翻源码，一眼看到Controller里堆了几十行业务代码，印象分立刻减半。时间格式转换、状态判断、事务控制这些都应该收在Service层。

3. SQL脚本背后的数据库设计：状态字段是整套系统的骨架

SQL脚本是“拿到手就能跑”的关键交付物。但脚本只是结果，真正值得你花时间研究的是脚本里的表结构设计。

3.1 核心表拆解：不是只有一张项目表

一套完整的大创系统，数据库通常包含以下核心表：

• sys_user：用户表，存学生、教师、管理员、专家的基本信息。
• sys_role和sys_user_role：角色表与用户角色关联表，实现RBAC权限模型。
• project_apply：项目申报表，这是最核心的表，一个项目一行记录。
• project_member：项目成员表，一个项目对应多个成员，多对多关系一定不能省。
• project_review：项目评审表，记录评审专家打分和意见。
• project_midcheck：中期检查表，存中期报告内容和审核结果。
• project_conclusion：结题申请表，存最终成果、成果附件、结题结论。
• notice：通知公告表，学校发布申报通知用。
• attachment：附件表，统一管理Word申报书、中期报告、结题材料的文件路径。

这些表之间最核心的关联是：project_apply作为主表，通过project_id关联成员、评审、中期检查、结题申请，sys_user作为操作者表。ER图在论文第四章是必须有的，画的时候重点标注主键外键，答辩老师非常喜欢围着ER图问表关系。

3.2 状态字段：为什么用int而不用字符串

project_apply表里一定要有一个状态字段，我建议定义为status，类型用tinyint或int，枚举值在代码里维护。比如：

0：草稿 1：待学院初审 2：待专家评审 3：已立项 4：中期检查中 5：待结题 6：已结题 7：已终止

有人喜欢用字符串直接存“草稿”“已立项”，这种设计在打印日志时确实直观，但数据库查询效率不高，而且写错一个汉字就是致命Bug。用int存，在代码里定义枚举类或常量接口，显示端再通过字典映射成中文标签，这是企业开发的通用做法。接口文档里一定要附上这张状态枚举表，不然前端根本不知道后端返回的status=3是什么意思。

3.3 评审表和附件表：容易被低估的两个设计点

project_review表的设计很容易犯一个典型错误：只在表里存一个总分字段。实际评审场景是多个专家给同一个项目打分，每人一个分数加一段评语，最终取平均分或去掉最高最低后的平均分。所以评审表要按“一次评审记录一行”来设计，project_id+reviewer_id+review_type加唯一约束，这样既支持多个评审人，也防止同一个人对同一项目提交多次打分。review_type区分是立项评审、中期评审还是结题评审。

attachment表则解决一个问题：文件名和路径不能写死在业务表里。项目申报书是一个文件，中期报告是一个文件，结题成果可能是一堆附件。统一在附件表里存文件原名、存储路径、上传人、上传时间，业务表只需要存一个attachment_id指向它。这样后续扩展“优秀项目成果展示”之类功能时，不需要动业务表结构。

SQL脚本里我还加了几条初始化数据：一个admin账号（密码建议用123456的加盐哈希值），三个学院管理员账号，以及若干学生和指导老师测试账号。导入后直接用管理员的账号密码登录，整套系统就能看到完整菜单。这条让我在给学生讲解时省了大量时间——不用从注册开始走流程，进去就是全权限演示。

4. 接口文档设计的背后逻辑：申报、评审、结题三主线如何实现

接口文档是标题里点名的交付物，一份好的接口文档不只是列URL和参数，还要能让人理解这个系统的业务约束。接口这里我挑三条最核心的流程来讲，这三条搞懂，其余接口都只是类似套路。

4.1 学生申报：状态机如何约束前端操作

学生发起项目申报，后端对应的接口就是POST /api/project/apply。接收参数包括项目名称、项目类型（创新训练/创业训练/创业实践）、成员列表、指导老师ID、项目周期、经费预算等。这里的核心逻辑是：首次提交时，如果项目之前不存在，则初始状态设为0（草稿）；如果项目已存在，则校验当前状态是否允许再次编辑提交。只有草稿状态的项目，学生才允许修改和删除；一旦状态变成1（待初审），前端对应的编辑按钮和删除按钮就该被禁掉。

状态流转的判断逻辑放在Service层统一处理，用一组静态常量定义合法流转关系，比如：

// 状态流转合法判断，非法则抛异常 if (!ProjectStatus.canTransition(currentStatus, targetStatus)) { throw new BizException("当前状态不允许执行该操作"); }

这种设计在答辩时非常好讲：状态机的引入避免了“一个setStatus搞定一切”的失控操作，每一步流转都有据可依。

4.2 专家评审：并发提交如何保证不重复打分

评审模块的接口是POST /api/review/submit，参数包含projectId、score、opinion、reviewType。这里最关键的点是事务和防重复提交。同一评审人可能在两个浏览器标签页里同时对同一个项目打分并点击提交，如果没有约束，数据库里就可能出现两条评审记录。

实现时先做唯一性校验和数据库唯一索引双保险：

@Override @Transactional(rollbackFor = Exception.class) public void submitReview(ReviewSubmitDTO dto) { // 校验是否已评审过 Integer count = reviewMapper.selectCount( new LambdaQueryWrapper<ProjectReview>() .eq(ProjectReview::getProjectId, dto.getProjectId()) .eq(ProjectReview::getReviewerId, dto.getReviewerId()) .eq(ProjectReview::getReviewType, dto.getReviewType())); if (count > 0) { throw new BizException("您已提交过该项目的评审意见"); } // 插入评审记录，同时更新项目状态 // ... }

评审完成后，项目状态从“待专家评审”变成“已立项”，这个动作同样需要在事务里执行。如果一个项目的所有专家都评完了，还需要汇总均分并回写到项目表里，方便列表页直接展示。这些逻辑都不复杂，但你要能讲清楚为什么用事务——因为“插入评审记录”和“更新项目状态”两个操作必须同时成功或同时失败，否则系统数据就前后矛盾了。

4.3 结题与中期检查：附件上传和状态回退的处理

中期检查和结题模块的逻辑很像，都是填表加传附件。后端接口会接收一个MultipartFile文件，然后把文件保存到服务器本地磁盘或云存储，把路径写入attachment表，再把attachmentId关联到中期检查表或结题申请表。文件上传其实有个很容易忽略的安全问题——必须对上传文件做类型校验和大小限制。只校验扩展名是不够的，一个改名叫.doc的脚本文件也可能被传上来，建议文件大小限制在20MB以内，类型白名单至少包含doc、docx、pdf、zip、rar。

结题还有一个值得设计的细节：审核不通过时，项目状态回退到“待结题”，但审核意见必须展示给学生。这不算复杂，但体现了“审批流闭环”的思想——任何一步审核都不能只有通过与不通过两个结果，不通过的理由要能推送到业务方，这在论文系统测试章节能多写两个测试用例。

4.4 通用能力：JWT身份认证与统一返回格式

接口文档里一定会有登录相关接口：POST /api/auth/login，校验用户名密码成功后，后端返回一个JWT令牌。前端把它存在localStorage里，每次请求在Axios拦截器中带上Authorization: Bearer <token>头。后端再写一个拦截器，对所有非登录接口做令牌校验。这里的拦截器不需要复杂，继承HandlerInterceptor或者实现OncePerRequestFilter都行，核心逻辑就是“解析token→拿到用户ID→放入ThreadLocal→放行”。

统一返回格式也很重要。所有接口的返回结构都应该是：

{ "code": 200, "message": "操作成功", "data": {} }

这样前端Axios在响应拦截器里统一处理code，不需要每个页面单独做错误判断。接口文档里如果能把公共返回体说明放到最前面，对接效率会高很多。

5. 前后端联调实录：这几个坑基本每个项目都会踩

就算后端接口写得再规范，前后端联调阶段依然会有一堆莫名其妙的问题。我从项目实践中总结了最常遇到的五个，每一个都有对应的排查思路。

5.1 跨域问题：开发环境用代理，生产环境配CORS

前后端分离项目第一个遇到的基本都是跨域。前端跑在http://localhost:8080，后端跑在http://localhost:8081，浏览器会把这两个不同端口的请求判定为跨域。

解决办法我建议开发环境用前端代理，在Vue项目根目录的vue.config.js里配置：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

注意这里的pathRewrite很容易配错。如果后端Controller的RequestMapping是/project/apply，前端请求路径写成/api/project/apply，代理会把/api前缀去掉再转发到后端。如果不知道后端接口到底有没有/api前缀，先看一眼Controller的@RequestMapping再决定配不配pathRewrite。很多人在这一步页面请求404，其实就是前缀没配对。

5.2 时间格式：数据库datetime变成了一串数字

后端返回给前端的日期字段，默认会被Jackson序列化成时间戳，前端拿到createTime显示成“1650000000000”这种数字，这会让用户以为程序写错了。

解决办法有两个，第一个是在实体类字段上标注@JsonFormat：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime createTime;

第二个是全局配置Jackson，在application.yml里设置：

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

两个方式都行，我更推荐全局配置，免得每个字段都要注解。配套的还有一个坑：前端Element UI的el-date-picker传值默认格式不是yyyy-MM-dd，需要在组件上加value-format="yyyy-MM-dd"，否则后端LocalDate接收时会直接解析失败报400。

5.3 雪花ID精度丢失：明明新增了一条记录，编辑时却查不到

MyBatis Plus默认的主键策略是ASSIGN_ID，生成的是雪花算法Long类型ID。问题在于Long类型最大值超过JavaScript的Number.MAX_SAFE_INTEGER（2^53-1），传到前端后精度丢失，最后几位变成0，于是你用这个ID去查询时查不到任何数据。

这个问题排查起来特别迷惑，因为后端日志里ID明明是对的，前端接收后却变了。解决方案是在返回前把Long类型转成字符串：

@JsonSerialize(using = ToStringSerializer.class) private Long id;

如果实体字段比较多，用全局策略更省事——在Jackson配置里统一将Long序列化为String。这个属于老生常谈，但每年都有人踩，专门写进文档里一定是值得的。

5.4 MyBatis Plus分页插件：页码正常但查出了全表数据

用MyBatis Plus的selectPage方法时，如果发现total有问题或者干脆查出了全部数据，先检查有没有配置分页插件拦截器。分页插件不是天生就生效的，需要显式添加配置类：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

这个坑不容易被立即察觉，因为不配置分页插件时selectPage并不报错，而是默默查出全部数据然后内存分页。数据量小的时候页面一样能分页显示，直到导出报表或者查看SQL日志才发现有问题。如果你之前在SQL脚本里准备了测试数据，这一步就能直观看到效果。

5.5 前端权限路由：解决了按钮显示问题，却漏了路由守卫

前端界面通常根据角色来显示不同的菜单，比如学生看到“项目申报”，专家看到“我的评审”。这只是页面级的控制，真正的安全控制一定要做两层——后端接口校验是强校验，前端路由守卫只是体验优化。

路由守卫通常在router.beforeEach里检查token和角色：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

以前出现过一种情况：前端菜单隐藏了“用户管理”，但有人直接输入/user/list路径就能访问页面，后端又没有校验角色，管理功能就暴露了。所以接口文档里的每个接口都写了“需要什么角色权限”，后端拦截器对所有非白名单接口做JWT校验，涉及角色权限的接口再在Service层做二次校验，比如学院管理员只能操作本学院的数据。

6. 论文撰写与答辩准备：评审老师最关注的几个技术细节

项目源码能跑起来只是第一步，对毕设来说，论文和答辩的分量可能比代码本身还重。很多代码写得不错的同学，答辩时反而被老师问住了，原因不是不会，而是从来没想过“我为什么这么设计”。

6.1 论文框架建议：六章把项目讲透

根据我见过的高分论文结构，这套系统可以按以下章节组织：

• 第一章 绪论：写研究背景与意义，强调国家推行创新创业教育、高校大创项目管理存在重复填报、进度不透明、数据分散等问题。
• 第二章 相关技术介绍：SpringBoot、Vue、MySQL、MyBatis Plus、Element UI，每样技术写清楚“是什么、为什么选它、在项目中用来干什么”。
• 第三章 系统分析：可行性分析（技术、经济、操作），需求分析（角色分析、用例图、业务流程），非功能需求（安全、性能、易用性）。
• 第四章 系统设计：系统架构图（前后端分离+三层架构）、功能模块划分、数据库设计（ER图、核心表结构说明）。
• 第五章 系统实现：按角色分小节，配页面截图，关键代码不要贴一大段，截几行核心代码加文字说明即可。
• 第六章 系统测试：功能测试（设计用例表格）、性能测试（简单压测结果）、兼容性测试。

6.2 答辩高频追问：这些问题一定要提前准备

以下是我整理的高频追问，每一个都对应一个能讲两分钟的设计片段：

1. “项目状态是怎么流转的？为什么不引入Activiti这类工作流引擎？”回答思路：当前状态机模型已覆盖全部业务路径，状态枚举清晰，小系统引入工作流引擎反而增加配置复杂度；后续如果学校流程变化，只需要增改状态枚举和流转规则，不需要重新部署引擎。

2. “评审的公平性如何保证？”回答思路：评审由校级管理员统一分配，支持随机分配与手动调整，评审人看不到申报学生所在学院等信息；评分采用去掉最高最低的均分策略，降低个别人为因素影响；数据库对同一项目同一评审人做了唯一约束。

3. “系统安全性做了哪些措施？”回答思路：用户密码采用加盐哈希存储，禁止明文保存；登录发放JWT令牌并做拦截校验；用户权限通过RBAC模型控制；SQL语句全部使用预编译方式，避免注入攻击；文件上传做类型和大小限制。

6.3 答辩演示顺序：先演示业务闭环，再展示技术亮点

演示系统的时候，不要上来就点菜单挨个展示页面，评委看十分钟就疲劳了。我建议按照“一个完整业务闭环”来演示：先用管理员账号登录，在通知管理里发布一条新的申报通知；切换到学生账号，填报一个项目并提交；再切换到学院管理员，做初审通过；再切换评审专家账号，进行打分；最后切回管理员账号，完成立项审核。整个闭环走下来，评委就明白你的系统完整覆盖了大创项目的全生命周期。

全程演示控制在8分钟以内，把状态变化、角色切换、审批环节展示出来，远比展示十个长得差不多的列表页面有效。代码层面，如果时间充裕，再打开Swagger或knife4j页面，展示一下接口文档的完整性和统一返回结构，这是加分项，说明你考虑到了前后端协作的规范问题。

拿到一套完整源码不是终点，把源码读透、把设计思路说出来才是这个毕设真正的收获。如果你能把数据库表之间的关系、状态机流转规则、权限控制逻辑讲到自己能画出来，那么无论是论文写作、代码答辩还是将来的工作面试，这段经历都会成为一份非常扎实的项目履历。