企业官网建设流程全解析

最近在整理一套用 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 打造的大学生创新创业训练项目管理系统（业内一般直接叫“大创管理系统”）源码，后台还带了配套的开发文档。这套系统在高校信息化里属于很典型的管理类项目，覆盖了学生申报、导师指导、专家评审、学院管理员结题归档的全流程，业务逻辑完整，技术栈又是当前 Java 前后端分离开发的主流组合。不管你是准备拿它当毕业设计、课程设计，还是想通过一个完整项目把 SpringBoot 和 Vue3 的配合彻底吃透，这套源码都值得从头到尾过一遍。

这篇文章我不打算做成说明书式的逐字段讲解，而是把它拆开揉碎，从“这套系统到底解决了什么问题”开始，讲业务模型、技术选型、核心模块、关键实现，最后再把我实操过程中踩过的坑和排查思路一并整理出来。读完你应该能对这类“高校管理信息系统”有一个完整的认知框架，也知道从零搭一套类似系统该怎么下手。

1. 项目到底在解决什么问题

1.1 大创项目管理的真实痛点

每年春季学期都是各高校“大学生创新创业训练计划”项目申报的高峰期。申报书提交、指导教师审核、学院初审、专家评审、中期检查、结题验收，一整条流程走下来，涉及的人员角色非常多。早期不少学校的管理方式还停留在“Excel 汇总 + 邮件收发申报书”，这就会带来一连串问题：

• 申报书版本混乱，学生改来改去，最后交上去的到底是第几版，谁也说不清。
• 评审专家分配不透明，纸质评审时专家之间看不到彼此的评分，人为干预空间大。
• 中期检查和结题的纸质材料散落在不同人手里，结题验收时想翻历史记录非常费劲。
• 最后统计各类立项数据、结题率、经费使用情况时，全靠人工从表格里复制粘贴，又慢又容易错。

而“大创管理系统”要解决的就是把这条业务流程整体搬到线上：学生在线填报申报书并提交附件，导师在线审核并填写指导意见，管理员统一分配评审专家，专家在线打分并签署意见，系统自动流转到下一步。整个过程留痕可追溯，所有材料按项目归档，最终统计数据一键导出。这不只是把表格变成了网页，而是把“流程”本身变成了系统里的状态机，每一份数据都有明确的状态和责任人。

1.2 四种核心角色与各自要干的活

从权限模型来看，这套系统围绕四个核心角色展开，每个角色在项目生命周期里承担完全不同的职责。

• 学生：创建项目申报书、填写项目成员信息、提交附件材料、查看审批进度、提交中期材料和结题材料。
• 指导教师：查看名下学生申报的项目，给出审核意见，记录日常指导过程，确认中期和结题材料的真实性。
• 评审专家：接收系统分配的项目评审任务，根据评分标准打分，填写评审意见，给出立项建议。
• 管理员（学院/校级）：维护用户账号和角色，配置申报窗口期，分配评审专家，处理异常流程，查看全院的申报和结题统计数据。

这种 RBAC（基于角色的访问控制）模型特别适合高校类管理系统，因为角色之间的界限非常清晰，页面能看什么、接口能调什么，都能在权限配置里直接约束住，后端的接口设计也能据此做细粒度的鉴权。

1.3 核心业务流程拆解

整个系统的业务主流程可以理解为一条项目状态机：

草稿/待提交 → 导师审核 → 学院初审 → 专家评审 → 立项通过 → 中期检查 → 结题验收 → 已归档

每一步都会有几个关键约束条件。比如：申报截止时间过了之后，学生不能再提交申报书；导师审核只能从待审核的列表里拿项目；专家评审阶段，只有被分配到的专家才能打分；中期检查未通过的项目，不能进入结题受理。这些约束本质上就是状态机里的“转移条件”，在代码里通常会用 if 判断 + 数据库状态字段来共同完成。

理解了这个流程，你再看源码里的项目表结构就会很清晰：一张 project_info 表存项目基本信息，一个 status 字段记录当前状态，额外的时间字段约束每个阶段的可操作窗口。后面所有复杂的查询报表，基本都是围绕这个主表和几个关联表做聚合。

1.4 这套系统适合谁来读

这套源码的参考价值主要在这几类人身上：

• 准备做毕业设计或课程设计的高年级学生，需要一套有完整业务闭环、技术栈主流的系统作为参考。
• 正在学 SpringBoot + Vue3 前后端分离开发的初中级开发者，想看看真实项目中表结构、权限、文件上传、状态流转是怎么落地的。
• 高校信息中心或教务管理人员，在规划本校大创管理系统时，需要一个经过业务验证的功能模板。

我个人觉得，它的定位更像是一个“高质量教学案例”，而不是一套复杂的商用平台，这正好是大多数读者最需要的那类东西。

2. 技术选型为什么是这套组合

2.1 前后端分离架构

这套系统采用的是目前主流的“前后端分离”架构，后端只提供 RESTful API，前端用 Vue3 做单页应用（SPA），两者通过 JSON 数据交互。

对比十年前那种“JSP + Servlet + 后端模板渲染”的方式，前后端分离带来的好处非常直接：前端开发和后端开发可以并行推进，互不阻塞；后端接口可以被 Web、小程序、移动端复用；部署时前端是纯静态文件，可以放到 Nginx 里，后端起一个 SpringBoot 应用，两者各自扩展互不影响。

对学习阶段的人来说，前后端分离还能帮助建立“接口契约”的概念。前后端各出一个接口文档，前端拿着 Mock 数据先开发页面，后端拿着 Postman 先调通接口，最后联调时只排查字段对不上的问题。这种协作方式基本就是现在企业里的日常。

2.2 后端为什么用 SpringBoot 2 而不是其他框架

在 Java 后端这个领域，SpringBoot 已经是事实上的默认选择。它把 Spring 生态中繁琐的 XML 配置全部收进了自动配置机制里，配合起步依赖（starter）可以做到“引入即用”。比如要引入 Web 能力，只需要在 pom.xml 里加一个 spring-boot-starter-web，内嵌的 Tomcat 就会自动启动，不用再配置 Servlet 容器。

关于 SpringBoot 2 和 SpringBoot 3 的取舍，这套系统选择 SpringBoot 2 是有现实考虑的。SpringBoot 2 基于 Spring 5 和 JDK 8，生态成熟度极高，MyBatis-Plus、各种 OSS 组件、老项目的迁移资料都非常丰富。而 SpringBoot 3 强制要求 JDK 17 和 Jakarta EE 命名空间，虽然性能更好，但不少第三方组件当时的兼容性还没完全跟上。很多高校的实验环境和企业生产环境仍以 JDK 8 为主，所以 SpringBoot 2 在兼容性和稳定性上更稳妥。如果你的环境已经全面切到 JDK 17+，直接升级到 SpringBoot 3 也没有问题，只是要注意部分依赖包的坐标变化。

2.3 ORM 层用 MyBatis-Plus 图什么

如果只是单纯用 MyBatis，你会发现大量简单的 CRUD 操作都要手写 SQL，表一多，重复劳动量非常大。MyBatis-Plus 在 MyBatis 基础上做了几个很实用的增强：

• 内置通用 Mapper，单表 CRUD 不需要写 SQL，一个 BaseMapper 接口直接搞定。
• 提供条件构造器 QueryWrapper/LambdaQueryWrapper，动态查询条件封装得相当优雅，不用反复拼接字符串。
• 自带分页插件，只要配置一个拦截器，分页查询的 count 和 limit 就自动处理了。
• 支持代码生成器，可以根据数据库表反向生成实体类、Mapper、Service、Controller，省掉大量机械编码时间。

但这里也要泼一盆冷水：MyBatis-Plus 适合“单表为主”的业务场景，遇到多表关联、复杂子查询、动态排序这种需求，该写 SQL 还是要手写 XML。大创管理系统这种业务，单表操作占绝大多数，复杂报表用少量联表 SQL 也能覆盖，正好把 MyBatis-Plus 的优势发挥到最大。源码里如果看到手写的 XML，大概率就是统计报表这类场景，这是合理的设计取舍。

2.4 前端用 Vue3 + Element Plus 是当下最顺手的组合

Vue3 在 2020 年正式发布之后，经过几年迭代已经非常稳定。它最大的变化是全面转向 Composition API（组合式 API），配合 setup 语法糖，逻辑复用能力比 Vue2 时代的 Options API 强了不止一个档次。

具体到大创管理系统这种管理后台类的项目，页面结构高度相似，无非是“左侧菜单 + 顶部导航 + 内容区表格”，所以前端 UI 组件库的选择非常重要。Element Plus 作为 Element UI 的 Vue3 版本，表单组件、表格组件、对话框、步骤条都很齐全，而且对中后台业务场景的覆盖度极高。Vite 作为构建工具，冷启动速度快，开发体验比 Webpack 时代流畅得多。

这套组合带来的直接好处是：一个学生申报页面，从表单校验到附件上传，再到表格分页展示，几乎不用自己造轮子，把组件接好就完事了。前端开发效率高，接入后端接口时只要注意字段命名规则，大部分时间都花在业务逻辑上而不是 UI 细节里。

2.5 数据库选 MySQL 8.0 的理由

MySQL 8.0 是当前生产环境最主流的关系型数据库之一。相比 5.7，它有几项非常实用的改进：

• 默认字符集是 utf8mb4，直接支持完整 Unicode，再也不用担心 emoji 入库报错。
• 支持窗口函数和公共表表达式（CTE），写复杂统计 SQL 时清晰很多。
• 支持 JSON 类型和 JSON 函数，某些弹性数据结构可以直接存在一个字段里，省掉关联表。
• 性能上有明显优化，特别是只读场景，查询计划器比老版本更聪明。

大创管理系统里的“历年项目统计”“各学院立项率对比”这类需求，用窗口函数可以写得非常简洁。比如要给每个学院的立项项目按申报时间排个名次，MySQL 8.0 的 ROW_NUMBER() 直接解决，而在 5.7 里你就得靠临时表或者变量绕来绕去。

需要特别提醒的是，MySQL 8.0 默认的认证插件改成了 caching_sha2_password，旧的 JDBC 驱动连不上。所以源码里用的数据库驱动类名是 com.mysql.cj.jdbc.Driver，而不再是老版本的 com.mysql.jdbc.Driver。这个细节在初次部署时最容易踩坑，后面我会在问题排查部分专门说。

3. 核心功能模块拆解与数据库设计

3.1 认证与权限设计：JWT + RBAC

管理系统首先要解决“你是谁、能干什么”的问题。这套系统的认证方案是典型的 JWT 模式：用户登录后，后端校验用户名密码，签发一个包含用户 ID 和角色的令牌（Token）返回给前端；前端把 Token 存到本地或内存里，每次请求带上；后端通过拦截器解析 Token，拿到当前用户身份。

源码里的实现路径一般是这样的：

// 后端生成 JWT 的核心代码示意 String token = Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 86400000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

这里用到了 JWT 的 claim 来携带业务信息，但要注意不要把密码等敏感数据放进 Token。Token 在客户端是可见的，就算做了签名，也只是防止篡改，而不是加密内容。

权限控制方面，RBAC 模型在三层都做了落地：前端通过路由守卫控制页面可见性，后端通过拦截器和注解控制接口访问权限，数据库里用角色表存储角色定义。管理员能访问用户管理、评审分配这些接口，学生就不能，否则会直接被拦在 403。

3.2 项目状态机的设计思路

“项目状态”是整个系统的灵魂。从学生新建申报书开始，到最后结题归档，项目的状态变化路径是固定的，这种场景非常适合用“状态机模式”来建模。

我建议你阅读源码时重点关注这几个状态的流转逻辑：

• 待提交：学生未点击提交按钮时，申报书只是草稿，可以任意修改。
• 待导师审核：学生点击提交后，状态变更为待导师审核，申报书锁定，学生不能再改。
• 学院初审中：导师审核通过后进入学院初审，管理员此时可以退回或者通过。
• 专家评审中：学院初审通过后，管理员分配专家，专家依次打分。
• 立项通过/未通过：系统汇总专家评分后，管理员根据总分给出立项结论。
• 中期检查中：立项通过后，到了规定时间点学生提交中期报告，导师和学院审核。
• 结题验收中：中期通过后，学生提交结题材料，专家进行验收评审。
• 已归档：结题验收完成，所有材料归档锁定。

状态字段在数据库里用一个 int 或者 varchar 字段存储，代码里通常会写一个枚举类来管理所有状态值。比如某个简单实现里，状态字段可能是这样定义的：

public enum ProjectStatus { DRAFT(0, "草稿"), SUBMITTED(1, "待导师审核"), COLLEGE_REVIEWING(2, "学院初审中"), EXPERT_REVIEWING(3, "专家评审中"), APPROVED(4, "立项通过"), REJECTED(5, "未立项"), MIDTERM_CHECKING(6, "中期检查中"), FINAL_CHECKING(7, "结题验收中"), ARCHIVED(8, "已归档"); }

这样做的好处是整个业务逻辑里不会出现魔法数字，代码可维护性高很多。而且后续如果要增加新的审批环节，只需要加一个枚举值，再在状态流转判断里补一条分支就行。

3.3 数据库核心表设计实战分析

看这套系统的数据库脚本，重点应该关注这几张核心表的结构和关联关系。

这个表结构有几个值得学习的细节：

• 项目信息表里同时存了 leader_id 和 teacher_id，分别指向学生用户和指导教师用户，都是外键逻辑关联，没有用物理外键约束。这样既保持了关系的清晰性，又避免了物理外键对写入性能的影响。
• 附件表和业务表的关联用的是 biz_type + biz_id 的组合，这是一种“多态关联”的设计思路。一个附件表可以同时服务项目申报书、中期报告、结题报告等多种业务，不用每种业务都建一套附件表。
• 密码字段存储的必须是加密后的密文，推荐 BCrypt 加密。源码里通常会用 Spring Security 的 BCryptPasswordEncoder 来处理，也可以自己集成相关的工具类。

4. 实操：从零搭建到跑通核心流程

4.1 环境准备与工程初始化

在动手之前，先把环境准备好。我的推荐配置是：

• JDK 8 或 11（SpringBoot 2.x 对这两者支持最稳）
• Maven 3.6+
• Node.js 16+，npm 或 yarn 之一
• MySQL 8.0 实例，建议提前创建好数据库并设置字符集为 utf8mb4
• Redis（可选，如果 token 体系要支持服务端主动失效，需要把 token 存一份在 Redis 里）

拿源码部署的第一步是倒数据库脚本。一般源码包里都会带一个 sql 文件，比如 init.sql，包含建库建表语句和初始化数据。导入完成后，检查数据库连接配置，重点是 application.yml 里的 datasource 和 MyBatis-Plus 相关配置：

spring: datasource: url: jdbc:mysql://localhost:3306/innovation_project?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

这里有个细节：url 里的 allowPublicKeyRetrieval=true 一定不能少。MySQL 8.0 默认的 caching_sha2_password 插件在首次连接时会要求客户端获取服务器的公钥，不加这个参数会直接报“Public Key Retrieval is not allowed”。

4.2 后端工程结构怎么组织最清晰

源码后端部分的分层结构非常标准，值得照抄：

src/main/java/com/example/innovation ├── controller // 接口层，只做参数接收和结果返回 ├── service // 业务逻辑层，核心逻辑都在这层 │ └── impl // 业务实现类 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── dto // 前后端交互的数据传输对象 ├── common // 通用返回对象、常量、异常处理 ├── config // 配置类，如 MyBatis-Plus 分页插件、跨域、JWT 过滤 └── security // 认证与授权相关组件

接口层（Controller）只做三件事：接收参数、调用 Service、返回统一结果。业务逻辑不要写在 Controller 里，否则后期一旦业务复杂，Controller 会膨胀到难以维护。通用返回对象建议设计成 Result ，包含 code、message、data 三个字段，前后端约定 code=200 表示成功，其他为各类失败。

4.3 后端核心实现示例

看源码时，建议优先看这几个核心实现，因为它们是整个系统的骨架。

第一个是 JWT 认证过滤器。它的作用是拦截所有请求，放行登录接口，对需要认证的接口解析 Token。一个简化版本的过滤器代码如下：

@Component public class JwtAuthenticationFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { Claims claims = Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token.substring(7)) .getBody(); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); } chain.doFilter(request, response); } }

这里要注意的是，Token 解析失败时不能直接抛异常，而是要统一走全局异常处理器，返回 401 状态码和错误信息，而不是让请求直接 500。

第二个是 MyBatis-Plus 分页插件配置类。很多同学运行项目后发现自己写的分页不生效，主要就是没配这个拦截器：

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

这个配置配好之后，Service 层直接用 Page 对象作为查询参数，MyBatis-Plus 就会自动生成 count 查询和 limit 语句，非常方便。

第三个是项目申报接口的核心逻辑。学生提交申报书时，后端要做的事情比想象中多：

@Transactional public Long submitApply(ProjectApplyDto dto) { // 1. 校验当前时间是否在申报窗口期内 // 2. 校验学生是否已经提交过同类项目 // 3. 保存 project_info，状态置为待提交 // 4. 批量保存 project_member 成员信息 // 5. 处理附件上传，保存到 attachment 表 // 6. 记录操作日志 // 7. 返回项目 id }

注意 Service 方法上的 @Transactional 注解。项目申报涉及多张表的写入，任何一步失败都应该回滚，否则会出现“项目主表有了、成员表没写入”这种脏数据。这是事务一致性问题，在管理系统中特别重要。

4.4 前端 Vue3 页面集成要点

前端部分，源码用的是 Vue3 + Vite + Element Plus 的组合。打开前端工程后，重点看这几个文件：

• vite.config.js：开发环境的代理配置，把 /api 下的请求代理到后端的 8080 端口，解决开发时的跨域问题。
• src/router/index.js：路由表定义，所有需要登录后才能访问的页面都挂在 meta 里做权限控制。
• src/utils/request.js：对 axios 的统一封装，请求拦截器里往 header 里塞 Token，响应拦截器里统一处理 401 和业务错误码。

以申报页面为例，页面结构大致是：一个大型表单（el-form），包含项目名称、项目类型、指导教师选择、成员列表、附件上传等字段。提交时调用后端接口，成功后刷新列表数据。

// API 调用示例 export function submitProject(data) { return request({ url: '/api/project/submit', method: 'post', data }) }

需要注意的一个坑是：Element Plus 的文件上传组件默认会把文件转成 FormData 提交，如果你的后端接口接收的是 JSON 格式，会发现文件字段传过去是空的。正确做法是用 el-upload 的 http-request 自定义提交逻辑，先调文件上传接口拿到返回的 filePath，再把这个路径拼到表单数据里一起提交。这套源码里基本都会采用这种“先传文件、后提交表单”的模式。

4.5 完整跑通一个业务闭环

我强烈建议你部署好之后，按照这条链路完整走一遍，基本上就能理解整个系统的运转方式：

1. 用管理员账号登录后台，创建一个学生账号和一个导师账号。
2. 切到学生账号，新建一个大创项目申报书，填好信息、上传附件、提交。
3. 切到导师账号，审核通过。
4. 切回管理员账号，通过学院初审，给项目分配两名评审专家。
5. 切到评审专家账号，打分并填写意见。
6. 回到管理员账号，汇总评分，执行“立项通过”操作。
7. 切回学生账号，提交中期报告、结题报告，走完后续流程。

走完这一步，你会发现所有操作都有记录，每个环节都能溯源，这就是这套系统的核心价值所在。

5. 常见问题与排查技巧实录

5.1 高频问题对照表

以下是这套系统从部署到上线过程中最高频的问题，我直接整理成了一份速查表：

5.2 顺手分享几个抓 Bug 的经验

第一，排查接口问题先看后端的全局异常处理器。一套完整的源码里，全局异常处理会拦截所有未捕获的异常并返回结构化的错误信息。遇到 500 时，不要只看前端报错，去控制台找后面的 cause 信息，十有八九是数据库字段类型不对或空指针。

第二，Token 过期导致的一系列“奇怪”问题。很多页面刷新后数据没了，或者某个操作莫名其妙 403，先检查 Token 是不是过期了。JWT 本身不存服务端状态，过期后客户端不会自动感知。前端的请求拦截器里应该对 401 做统一处理，跳转回登录页，而不是让用户卡在半路。

第三，文件存储路径要注意。很多项目在开发环境把文件存到本地磁盘，部署到服务器后路径变了，导致上传成功但访问下载 404。源码里如果支持配置 storage-path，一定要在部署时改成服务器的绝对路径，并确保 Web 层能映射到这个目录。

5.3 关于这套源码的延伸思考

把这套系统跑通之后，你可以再往这几个方向扩展，训练自己的业务设计能力：

• 增加“申报时间窗口配置”功能，让管理员在后台设置申报开始与截止时间，系统自动控制提交接口的开关。
• 增加“专家回避逻辑”，避免某位专家评审自己指导的学生项目。
• 增加“统计报表模块”，用 MySQL 8.0 的窗口函数按学院、项目类型统计立项率和结题率，输出图表。
• 把附件存储从本地磁盘搬到对象存储服务，文件管理和容量规划会更轻松。

我个人在实际操作中的体会是：这类管理系统的难点从来不在某个单独的技术点上，而在于你对业务流程的理解深度。状态机设计得好，后续加需求非常顺畅；状态机设计得随意，后面每个功能都会跟状态判断纠缠不休。另外，多花时间在看数据库表关系上，永远比埋头调接口收获更大。表设计一旦把业务表达清楚了，剩下的事情基本都是顺着逻辑平推。希望这篇文章能帮你把大创管理系统这个项目吃透，也祝你在自己的项目上一路顺畅。