企业官网建设流程全解析

学生的创新创业训练项目，这几年在高校里越铺越广。但项目管理的模式，很多还停留在“学院汇总Excel、教务处收纸质材料、评审看扫描件”的阶段。真正上手做过的人都知道，一个项目从申报、评审、立项、中期检查到结题验收，材料多、节点多、参与角色多，全流程靠人肉盯根本盯不住。这也是我当初花力气做这套“SpringBoot+Vue+MyBatis+MySQL”架构的企业级大学生创新创业训练项目管理系统的原因。

这篇博文不打算讲虚的，直接以完整源码级视角，拆解这个系统的设计思路、数据库建模、核心模块实现、本地部署过程，以及我在实际开发中踩过的坑。内容适合正在做毕业设计、想接手类似管理系统项目、或者准备把校内流程线上化的开发者参考。至少你可以少走几个月的弯路。

1. 项目概述与需求拆解

1.1 大创项目管理的核心痛点

大学生创新创业训练项目，一般简称“大创项目”。每个学校的管理流程大同小异，但核心环节基本固定：学生申报、指导教师审核、专家评审、立项公示、中期检查、结题验收。这中间还有经费填报、成果登记、延期申请、终止申请等分支操作。

我最初接触这个需求时，第一反应不是写代码，而是把流程图画清楚。因为管理系统的核心，从来不是功能堆砌，而是状态流转是否严谨。学生填错一个状态，管理员就得在后台手动改数据，时间一长系统就会变成一张“补丁网”。

所以，这个项目的核心目标可以归纳为：

• 把项目全生命周期管理线上化，替代手工报表；
• 支持管理员灵活配置评审专家和评审批次；
• 学生端、教师端、专家端、管理员端四种角色分权管理；
• 每类项目材料支持附件上报，并保留版本记录；
• 为后续统计分析和数据导出打基础。

这套需求听起来常规，但真正落地时，很多细节比预想中复杂得多。比如同一个项目在不同阶段需要提交不同模板。申报阶段交申报书，中期阶段交进展报告，结题阶段交结题报告和成果附件。如果一张表把字段全放开，前端页面就会失控，后端校验也会无从下手。所以设计阶段，我采用了一种“基础表+阶段明细表”的组合方式，后面在数据库章节展开细说。

1.2 技术选型背后的考量

这套系统选择SpringBoot+Vue+MyBatis+MySQL，不是单纯因为“这套技术栈比较流行”，而是基于项目特性做的取舍。

后端选SpringBoot，看中的是生态成熟、起步快，内嵌Tomcat后部署非常省事。配合Maven管理依赖，打包成单个jar文件就能跑，这点对后面部署到学校服务器非常友好。再深一层，SpringBoot对事务管理、定时任务、文件上传都有现成方案，不需要自己造轮子。

选MyBatis而不是JPA，核心原因是这类管理系统的SQL逻辑相当复杂。比如统计不同学院的项目申报数量、汇总专家评审分数、查询某个学生的项目列表，都是典型的多表关联查询。用MyBatis可以把SQL写在XML里，学习成本低，排查问题直观。

前端选Vue，主要看中它的组件化能力与生态。Vue配合Element UI组件库，做后台管理的表单、表格、树形结构，效率极高。同时Vue的响应式机制，让数据回显和状态切换非常自然。

MySQL作为存储层，完全够用，部署运维简单，七千块钱买个带大内存的云主机都能扛住一个中等规模高校的使用量。

我见过不少团队为这种系统引入微服务架构，最后反而把简单问题搞复杂了。单体应用、清晰分层、可靠事务，才是这类业务系统的正解。

2. 系统总体架构设计

2.1 前后端分离的整体结构

这套系统按照前后端分离方式组织，前端和后端独立部署，通过HTTP接口通信。

前端采用Vue 2的成熟版本，配合Vue Router做路由控制、Vuex做全局状态管理、Axios发请求。页面结构分成公共布局和业务视图两部分，所有业务页面统一挂在Layout框架下。左侧菜单根据登录用户的角色动态生成，不同角色看到的菜单入口完全不同，这一点是权限控制在前端的第一层体现。

后端采用经典的Controller-Service-Mapper三层架构：

• Controller层负责接收请求、参数校验、统一返回结果；
• Service层承载业务逻辑，事务控制落在这一层；
• Mapper层只负责与MySQL交互，SQL写在XML中。

这样一个清晰的分层结构，最大的收益就是可维护性。举个例子，修改“立项评审通过后的项目编号生成规则”，只需要改Service层的几行代码，完全不用碰Controller和Mapper。

前后端通信统一走JSON格式。每个接口都返回统一定义的结构：

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

前端根据code值判断是否处理成功，不直接用HTTP状态码判断业务结果。这个看似不起眼的约定，在后面排查接口问题的时候帮我省了大量时间。

2.2 登录认证与角色权限控制

管理系统最容易出现的安全问题，就是接口越权。一个普通学生懂点抓包工具，直接篡改请求里的用户ID，去查询别人的项目信息，就是大事故。

所以这个系统没有只靠前端隐藏按钮来控制权限，后端对每个请求做了两层校验：

第一层：登录令牌校验。用户登录后，后端生成基于JWT的Token返回给前端。前端在每次请求的Header中带上这个Token，后端通过拦截器统一校验合法性。

第二层：RBAC权限模型。用户、角色、菜单、接口权限四张核心表关联。后端在Controller接口上加自定义注解，比如@RequirePermission("project:review")，拦截器在处理请求前先判断当前用户是否拥有这个权限码。

这么做的好处是，即使前端的按钮显示逻辑被篡改，后端依然会拦截无权限请求。所有敏感操作，判断权永远在后端。

2.3 多角色视图与Sprint设计思路

四类角色的业务视图，我按照一个完整的校级大创项目生命周期来设计：

这个表格看起来简单，但每个页面背后都牵扯一整套流程状态机。比如学生提交申报书以后，项目状态变为“待学院审核”。学院审核通过后，状态变为“待专家评审”。专家评审结束后，管理员要根据汇总分数决定“立项”或“不立项”。每一个状态变迁都必须在后端代码里显式定义，不允许出现跳变或者非法流转。

3. 数据库设计与核心表结构

3.1 核心表设计思路

数据库是这个项目的基石。我遵循的核心原则是：能拆的表不要合一，能规范的字段不要随意。

系统中主要的表有：用户表、角色表、菜单表、项目申报表、项目阶段材料表、评审表、评审专家分配表、项目变更记录表、公告通知表、字典配置表。

这里我重点说一下项目相关表的建模思路。

项目主表project_info的设计，选择把项目通用信息放一起，包括项目名称、项目类型、负责人ID、指导教师ID、学院ID、状态、立项年度、项目编号等字段。

而不同阶段提交的材料内容，放在project_stage_material表里：

CREATE TABLE project_stage_material ( id BIGINT PRIMARY KEY AUTO_INCREMENT, project_id BIGINT NOT NULL COMMENT '项目ID', stage_type TINYINT NOT NULL COMMENT '阶段类型：1申报 2中期 3结题', file_name VARCHAR(255) NOT NULL COMMENT '材料名称', file_url VARCHAR(500) NOT NULL COMMENT '存储路径', submit_user_id BIGINT NOT NULL COMMENT '提交人', version INT DEFAULT 1 COMMENT '版本号', submit_status TINYINT DEFAULT 0 COMMENT '0草稿 1已提交', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

为什么要单独拆这张表？因为申报书、中期报告、结题报告的字段差异很大，如果都用通用字段存，查询时就得频繁判断类型，前端渲染也要写一堆v-if。拆成独立阶段表，配合阶段类型字段，就可以根据不同阶段拉取不同模板，灵活得多。

同时设计version字段来支持“重新提交”的场景。学生提交中期报告后如果被驳回，修改后再提交，系统不是直接覆盖原记录，而是插入一条新版本记录。这样保留了项目过程性材料的完整痕迹。

3.2 项目生命周期状态机设计

项目管理系统的核心命脉是状态机。我在数据库层面设计了一个状态字段project_status，取值如下：

0 草稿 1 待学院审核 2 待专家评审 3 待管理员立项 4 已立项 5 待中期检查 6 中期已通过 7 待结题验收 8 已结题 9 已终止 10 已驳回

状态字段不直接存中文字符串，而是统一存数字，中文名称在代码枚举类中维护。这样做的好处是，将来改文案不需要动数据库；而且状态码可以参与条件查询，比如“查询所有待专家评审的项目”只需要一条简单的等值查询。

状态流转是强规则约束。我在Service层封装了统一方法，不合法流转直接抛业务异常。例如：

if (!ProjectStatus.canTransit(currentStatus, targetStatus)) { throw new BizException("非法的项目状态流转：" + currentStatus + " -> " + targetStatus); }

这里我用数据库表project_status_log记录每一次状态变更，包括旧状态、新状态、操作人、操作时间、备注。将来有纠纷报告，直接拉这张表复盘即可。

4. 核心功能模块的落地实现

4.1 学生端：项目申报与材料上传

学生端的核心功能就是项目申报。整个申报流程，我拆成了三个子步骤：填写项目基本信息、上传申报材料附件、确认提交。

关键技术点集中在文件上传上。这类的文件类型比较杂，可能有Word、PDF、Excel、图片、压缩包，所以后端上传接口不限制文件类型，而是做大小限制和扩展名白名单校验。

后端使用MultipartFile接收文件，上传到服务器的指定路径，然后在数据库记录文件的访问相对路径。我建议生产环境把文件放到单独的磁盘目录或对象存储里，项目文件以年/项目编号/文件类型这种方式存储：

/upload/2025/PROJ2025001/declaration/申报书.docx

这样按项目维度归档，后续打包归档非常方便。我在本地开发时用的是常规本地存储，部署到学校服务器时生产环境换成了独立大容量磁盘目录。

学生端上传时要做大小限制。Element UI的Upload组件配合自定义校验，我卡的是单个文件不超过50MB，整体材料不超过200MB。这只是一种比较稳妥的常规做法。

4.2 导师与评审端：审核与打分逻辑

导师端功能相对简单，核心是查看名下学生项目、填写审核意见、确认推荐。这里的业务逻辑是：导师审核通过后，项目才能进入下一环节。导师驳回后，项目回到学生草稿状态。

评审端相对复杂。管理员先创建评审批次，然后从专家库中选取专家，并把待评审项目分配给不同专家。

专家的评审动作是打分制。系统内置一套评分模型：选题意义30分、方案可行性30分、创新性20分、团队配置20分，总分100分。每个评审专家独立打分，系统自动计算平均分，作为立项排序依据。

这里有一个容易忽略的细节：评审专家不能看到其他专家的打分结果。所以在查询接口里，打分详情表按专家ID隔离，只有管理员有权限查看全部打分。这个细节如果漏了，轻则影响评审公正，重则整个系统的公信力就没了。

4.3 管理员端：批次管理与过程管控

管理员端是整个系统里业务逻辑最重的模块。我把重点功能拆成四块：

批次管理：每年度的大创申报，管理员先创建批次，设置申报开始时间、截止时间、专家评审时间。学生只能在批次开放时间窗口内进行申报，时间结束后系统自动锁定，不能再提交。这个时间窗口的锁定逻辑，我在后端做了双重校验——页面按钮禁用只是辅助，真正的校验在Service层。

项目审核：管理员可以对学院提交的项目进行最终立项审核。审核时可修改项目类型、分配项目编号，也可以驳回。

专家分配：管理员从专家库勾选专家，系统自动将待评审项目按“随机+学科匹配”原则分配给专家。为了避免某个专家评审自己指导的项目，分配时还要做排重校验，如果匹配到关联关系，自动跳过。

数据导出：项目清单、评审汇总表、结题情况统计都以Excel导出。我用的是EasyExcel，异步生成后存储在临时目录，同时提供下载链接。

这里值得强调的是管理员操作时，所有关键动作都要求二次确认。前端弹窗确认只是体验层面的，后端统一在Service层加上了状态校验，避免并发场景下同一个项目被两个管理员同时操作造成数据错乱。

5. 从源码到运行：本地搭建全流程实录

5.1 环境准备与初始化

如果你拿到这套源码，想在本地跑起来，需要先准备以下环境：

• JDK 1.8及以上
• Maven 3.6及以上
• Node.js 14.x及以上
• MySQL 5.7或8.0
• Redis（用于存储验证码和临时会话，如果不需要验证码也可先跳过后端配置）

我建议使用IDEA开发工具，后端导入Maven项目，前端用VSCode或WebStorm都行。

MySQL初始化时，要特别注意字符集设置，避免中文乱码：

CREATE DATABASE IF NOT EXISTS `innovation_project` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后把项目里的sql/init.sql脚本导入数据库。脚本里包含了表结构、初始菜单数据、初始管理员账号和演示数据。这里提醒一句，初始管理员密码一定要了解清楚，默认一般是admin/123456，正式上线前必须强制修改。

5.2 后端启动步骤与踩坑点

后端项目导入IDE后，等待Maven下载依赖。首次构建比较耗时，如果网络环境不好，容易卡在依赖下载阶段，建议配置阿里云Maven镜像。

修改application.yml中的数据库连接配置：

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

这里的serverTimezone=Asia/Shanghai必须加上。当年我第一次部署时没加这个参数，结果所有时间字段都比正常时间早了8小时，排查了半天才发现是MySQL驱动8.x对时区处理变更导致的问题。

直接运行启动类的main方法，控制台出现“Started Application in xx seconds”就代表后端启动成功。默认端口是8080，可通过server.port调整。

5.3 前端构建与联调流程

前端项目在frontend目录下，先安装依赖：

npm install

依赖安装完成后启动开发服务器：

npm run serve

前端默认端口是8080，与后端端口冲突，需要在vue.config.js里把端口改掉，并且配置代理转发到后端地址：

module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

这里有个经验，前端所有请求路径都加了/api前缀，后端通过统一拦截器做路径处理。这样前端联调时不用关心后端真实路径，部署时也方便用Nginx做路径转发。

启动完成后浏览器访问http://localhost:3000，用管理员账号登录，应该能看到完整的菜单和后端返回的数据。如果页面空白或者数据加载不出来，九成是代理配置或跨域问题，按下键盘F12看Network面板请求的返回状态即可快速定位。

6. 常见问题与排查技巧

6.1 数据库连接报错汇总

这套系统部署过程中，最常出现的报错就是数据库连接失败。我整理了一份高频问题对照表：

6.2 前端请求接口连不通

一个非常典型的问题是，前端配置了代理但请求还是404或500。我的排查步骤是：

1. 先看后端控制台有没有对应日志，没日志就是请求没到后端；
2. 直接访问后端地址测试，比如http://localhost:8080/api/project/list，通了说明后端没问题；
3. 检查前端代理配置，确认target指向的是后端地址；
4. 看请求的完整URL，确认是否走了代理前缀。

特别提醒，如果使用Nginx部署生产环境，需要把/api路径直接proxy_pass到后端服务端口，这块配置写错，前端必挂。

6.3 文件上传失败与存储目录问题

文件上传接口报“目录不存在”或“无权限写入”，是权限配置没做好的典型表现。我在Linux服务器上部署时，曾因为没有给上传目录设置写权限，导致学生端上传附件全部失败。

我的建议是，把上传目录独立配置到配置文件中：

myapp: upload-dir: /data/innovation/upload

然后预先创建好目录并授权：

mkdir -p /data/innovation/upload chmod -R 755 /data/innovation/upload

还有一点，SpringBoot的默认单文件上传大小限制是1MB，如果不修改配置，稍微大一点的材料附件的上传都会失败。需要在配置中放开限制：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 200MB

6.4 生产部署与性能优化要点

本地跑通只是第一步，真正部署到校园服务器时，有些点需要提前布局。

后端我建议用Maven打成jar包，用nohup后台运行：

mvn clean package -DskipTests nohup java -jar innovation-project.jar --spring.profiles.active=prod > app.log 2>&1 &

前端执行npm run build，生成dist目录，交给Nginx托管：

server { listen 80; server_name your-domain; root /data/innovation/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; } }

还要注意，Vue是单页应用，路由采用History模式时，Nginx必须配置try_files，否则刷新页面就是404：

location / { try_files $uri $uri/ /index.html; }

数据库层面，我给常用查询字段加了索引，比如project_status、user_id、project_id。大创项目系统的数据量并不算大，只要索引用得到，性能都不是瓶颈。真正要注意的是，不要写出不带条件的全表扫描SQL，统计汇总类查询尽量加时间范围过滤。

写在最后的一点实在话

这套系统前前后后改了三轮，从最初的一个简单CRUD demo，逐渐长成了覆盖申报、评审、立项、中期、结题全流程的完整管理系统。回头看，最有价值的不是代码量，而是对业务状态流转的深入理解。技术层面SpringBoot+Vue+MyBatis+MySQL这条链路，是极稳妥的组合，能帮你支撑起绝大多数高校内部管理系统的需求。

如果你拿到源码后想二次开发，我个人建议第一件事先读懂数据库表结构和状态机定义，再去看Service层的核心逻辑，最后才是Controller和前端页面。顺序对了，效率差一倍。按这个顺序来，你很快就能把项目跑起来，并且有底气往下改。