企业官网建设流程全解析

做完了这个大创管理系统，再回过头看标题里强调的"源码 + SQL脚本 + 接口文档"这三样东西，我的感受特别直接：一套能跑的代码并不稀奇，稀奇的是把业务状态、表结构、接口约定这三条线同时理清楚。很多同学拿到的项目要么只有代码没有数据库脚本，要么接口文档缺失只能对着源码猜，等你真把项目跑起来准备答辩的时候，才发现处处是坑。这篇内容我就围绕这套SpringBoot+Vue的大创管理系统，从业务拆解、技术选型、数据库设计、接口文档、部署排错这几个角度，把我实际开发验证过程中积累的东西完整捋一遍，适合正在做大创、毕设、课设的Java Web方向同学参考。

1. 大创管理系统到底在管什么：业务场景与功能梳理

1.1 大创项目的完整生命周期

"大创"全称是大学生创新创业训练计划，本质上是把国家级、省级、校级三级立项的创新创业项目从申报到结题的全流程数字化。如果不懂业务就开始写代码，大概率会把系统做成一个增删改查的堆砌物，答辩时老师问"你的审核流程怎么设计的"就卡壳了。

大创项目的生命周期一般是这样走的：

1. 申报阶段：项目负责人（学生）在线填写申报书，包括项目名称、项目类别（创新训练/创业训练/创业实践）、项目简介、预期成果、经费预算，然后指定指导教师。
2. 评审阶段：学院管理员对本院学生提交的申报书做初审，通过后进入校级终审；校级管理员组织专家评审，确定立项名单、项目等级（国家级/省级/校级）和经费支持额度。
3. 中期检查：项目执行到中期，学生需要提交中期检查报告，指导教师审核签字，学院汇总上报。未能通过中期检查的项目会被警告甚至终止。
4. 结题验收：项目执行期满，学生提交结题申请书、结题报告、成果材料（论文、专利、软著、竞赛获奖等），专家评审打分给出结题结论。
5. 成果归档：结题通过后，系统里保留完整的项目档案，方便后续优秀项目评选、成果统计和经费审计。

明白了这条主线，你就知道管理系统里最核心的不是"增删改查"本身，而是状态流转。一个项目从草稿、已提交、学院审核中、学院驳回、校级审核中、立项、中期检查中、结题申请中、已结题……每一个状态都要有对应的操作和记录。

1.2 角色权限与功能模块的对应关系

这套系统我按角色划分了五个维度的权限，对应关系整理如下：

背后的权限设计思路其实不复杂：用户表里通过role字段区分角色，后端接口在拦截器里做白名单过滤，前端用路由守卫控制菜单和页面可见性。以这类系统的体量，完全不需要上Spring Security的完整权限模型，反而用轻量级的JWT + 拦截器更直观、更好答辩。

2. 为什么是SpringBoot+Vue：这套组合在毕设里的真实分量

2.1 后端选SpringBoot的原因与版本陷阱

SpringBoot在Java Web毕设里几乎是"标准答案"，原因很务实：内嵌Tomcat、自动配置、starter机制让项目启动只需要跑一个main方法，省掉了传统SSM里大量繁琐的XML配置。如果换成SSH或者纯Servlet来写大创管理系统，光配置文件就够折腾几天的，留给业务开发的时间会被严重压缩。

但是选版本的时候要克制。我的建议是：

• Spring Boot 2.7.x + JDK 8/11 + MySQL 5.7/8.0，这是最稳妥的组合。网上资料最多、踩坑案例最全，你遇到问题一搜基本都有答案。
• 如果为了"显得新"选Spring Boot 3.x，注意它最低要求JDK 17，并且javax.servlet要换成jakarta.servlet，很多老代码和教程直接粘贴会报错，持久层框架也要确认是否适配新版本。不是不能用，而是对于要交付验收的毕设来说，稳定压倒一切。

项目里我用的持久层是MyBatis Plus，相对原生MyBatis最大的好处是单表CRUD不用写SQL，内置分页插件也省事。业务里真正需要手写SQL的地方集中在多表关联统计，比如"按学院统计立项数量""按年度统计经费总额"，这种场景用一条带连表查询的SQL比在Java里做内存拼接靠谱得多。

2.2 前端Vue选型与后端打包的配合

前端我选的Vue 2 + Element UI，配合Vue CLI脚手架。有人问都202X年了为什么不直接上Vue 3，这里有个很现实的原因：Element UI对Vue 2的支持最成熟，后台管理系统的表格、表单、弹窗、树形控件开箱即用；Vue 3对应的Element Plus虽然也在成熟，但版本迭代中API变动比较频繁，对不熟悉前端的同学来说，照着一套Vue 2 + Element UI完成的代码改起来性价比更高。

前端结构上我按模块拆了路由和视图：

• views/project/：项目申报、项目列表、项目详情
• views/review/：学院初审、校级终审、结题评审
• views/user/：用户管理、指导教师管理
• views/fund/：经费预算、经费使用记录

Axios请求统一封装在utils/request.js里，设一个baseURL（开发环境指向后端http://localhost:8080），拦截器里统一携带token字段，后端返回4001时自动跳转登录页。这种做法能让前后端联调时减少非常多重复劳动。

2.3 为什么这个组合是Java Web毕设的"标准答案"

这套组合之所以被无数毕业设计采用，本质原因在于"性价比"：SpringBoot帮你解决了80%的配置问题，Vue帮你解决了80%的页面交互问题，剩下的精力可以全部投入业务本身。而且招聘市场对这个技术栈的认可度很高，你在答辩里能讲清楚"我在SpringBoot里如何设计拦截器做鉴权、在Vue里如何通过路由守卫控制权限"，本身就是面试加分项。

3. 数据库设计与SQL脚本：一张架构图理清所有表关系

3.1 核心数据表的设计逻辑

数据库是整个系统里我最看重的部分。表结构设计得合理，后端的代码写起来会非常顺手；设计得不合理，每加一个功能都要返工。大创管理系统的核心表我用这张清单来概括：

这里有三个设计点我特意强调一下。

第一，用户表单表设计。很多教程喜欢把学生、教师、管理员拆成三张表，再用用户角色关联表去映射，这对大创系统来说过度设计了。单表加role字段足够支持登录和权限判断，代码量少一半，逻辑也更清晰。

第二，审核记录表独立存在。审核动作不能只是改一个状态字段，关键是要留痕。每一条审核意见、每一次驳回理由都要落到review_record表里，项目详情页就能按时间倒序展示完整审核链路。答辩时老师最常问的就是"项目被驳回后从哪里能看到原因"，有这个表就非常从容。

第三，逻辑删除替代物理删除。所有业务表加一个deleted字段，删除操作统一走update而不是delete。原因很简单：毕设项目不需要追求极致的写入性能，但需要保证数据可追溯。误删一条报错可以恢复，这在演示系统时是实打实的保险。

3.2 SQL脚本里容易忽略但决定成败的细节

标题里专门强调了SQL脚本，说明这个文件不是随便导出一下表结构就完事的。我提供一个可以照着检查的清单：

• 建库语句要指定CHARACTER SET utf8mb4和COLLATE utf8mb4_general_ci，不然插入中文姓名或表情符号会乱码，MySQL 8.0默认字符集虽然是utf8mb4，但手动指定更保险。
• 每个表的id用自增主键或雪花ID都行，但如果你是MyBatis Plus，建议直接配IdType.AUTO，插入后能立刻拿回主键值。
• 初始化数据绝不能少。管理员账号、学院列表、项目类别字典这类基础数据必须在SQL脚本里就insert进去，不然前端登录入口都是空的。
• 演示数据要有。我往SQL里塞了20条左右模拟项目记录，覆盖"已提交、学院驳回、已立项、结题中"等各种状态。为什么一定要有？因为答辩演示时，你不能现场新建几十条数据去展示列表效果，有现成的演示数据直接截图都能当系统亮点。
• 外键约束看情况加。物理外键在这套系统里我基本没加，因为项目状态是逻辑流转的，物理外键在联表删除时会带来麻烦；表与表的关系通过字段命名约定（如project_id）在业务层维护，这是目前主流开发习惯。

4. 核心功能模块的实现拆解：从登录到结题的全链路

4.1 登录鉴权：JWT配合拦截器的轻量方案

登录这块我最初考虑过Spring Security + JWT，后来发现配置期太长，踩坑期更长，果断换成了"手动JWT + HandlerInterceptor"方案。思路是这样的：

用户登录成功后，后端用jjwt生成一个包含userId和role的token，返回给前端。前端Axios拦截器把token塞进请求头Authorization，后端写一个JwtInterceptor统一从Header里取出token、校验签名、解析用户信息，放到ThreadLocal里供后续业务代码直接取用。不需要权限控制的接口（比如登录）在注册拦截器时用excludePathPatterns排除即可。

这个方案不用引入大量框架依赖，代码量大概一百行出头，但足够解释和答辩了。常见的问题是token过期时间怎么定，我一般设置24小时，并在前端路由守卫里判断token存在与否，过期就跳登录页并清除本地缓存。系统的安全性需求本身不高，做到这一步已经完全足够。

4.2 项目申报与审核流程的状态机设计

项目的状态流转是整个系统最值得展开讲的部分，代码上我用了状态常量来避免魔法数字：

// 项目状态定义 public static final int DRAFT = 0; // 草稿 public static final int SUBMITTED = 1; // 已提交，待学院初审 public static final int COLLEGE_PASS = 2; // 学院初审通过，待学校终审 public static final int COLLEGE_REJECT = 3; // 学院驳回 public static final int SCHOOL_PASS = 4; // 校级立项通过 public static final int SCHOOL_REJECT = 5; // 校级驳回 public static final int MIDTERM_CHECKING = 6; // 中期检查中 public static final int MIDTERM_PASS = 7; // 中期检查通过 public static final int CONCLUDING = 8; // 结题申请中 public static final int CONCLUDED = 9; // 已结题

学生提交立项申请时，project.status从DRAFT变为SUBMITTED；学院管理员审核后，要么进入COLLEGE_PASS等待校级终审，要么变为COLLEGE_REJECT且必须填写驳回理由；校级终审同理。这样设计的好处是，前端每个按钮的显示逻辑都绑定在状态值上——比如只有"已立项"状态的项目才能申请中期检查，只有"中期检查通过"的项目才能提交结题申请。逻辑清晰、不容易串场，评审老师看着也舒服。

审核动作的接口实现也不复杂：先校验当前状态是否允许该操作，然后插入一条review_record记录，最后更新project.status。三步在一个事务里完成。这里有一个容易被忽略的点：多人同时审核同一个项目时可能产生状态竞争，虽然毕设不需要分布式锁，但至少要在SQL里加上WHERE status = 当前状态的条件更新，保证了状态不会从"学院审核中"直接跳成"已结题"。

4.3 文件上传与经费管理的落地细节

大创管理的核心业务里，文件上传绕不开：申报书要传PDF，结题成果要传论文、专利证书扫描件、软著截图。我用的方案是本地磁盘存储 + UUID重命名：

String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString() + suffix; File dest = new File(uploadDir, newFileName); file.transferTo(dest);

数据库里存的字段是相对路径，访问时通过一个/files/{filename}接口映射到磁盘目录。虽然生产环境更推荐阿里云OSS这类对象存储，但毕设场景里本地存储更直观，还能在答辩现场演示文件真实落在服务器哪个目录，反而更有说服力。唯一的注意点是上传目录的路径别写死成绝对路径，放到配置文件里，不然换电脑跑项目就会踩"文件找不到"的坑。

经费管理模块相对独立，本质是两张表：项目预算表 + 经费使用明细表。预算在立项时写入，学生使用经费时提交申请记录，管理员审核；页面展示用饼图/柱状图统计"已用金额/预算总额"的占比。这个模块代码量不大，但图表展示会让整个系统的完整度视觉上提升一大截，强烈建议保留。

5. 接口文档的价值：别把前后端联调变成猜谜游戏

5.1 一份合格接口文档应该包含什么

标题刻意提到"接口文档"，说明它在这套项目里是被当作核心交付物对待的。我整理接口文档时坚持的原则是：任何字段都必须在文档里能找到出处，任何返回码都必须在文档里有明确含义。具体到每个接口，至少要包含：

• 接口名称与功能简述
• 请求URL与请求方式（GET/POST/PUT/DELETE）
• 请求参数：字段名、类型、是否必填、含义说明
• 返回示例：完整的JSON结构，不能只写"成功返回data"
• 业务错误码：比如"1001 项目不存在""1002 无权限操作""1003 状态不允许该操作"

举一个立项审核接口的返回示例：

{ "code": 200, "message": "审核成功", "data": { "projectId": 12, "currentStatus": "SCHOOL_PASS", "reviewer": "张老师" } }

文档工具的选型上，我建议用Apifox这种支持在线分享和Mock数据的工具。它可以把每个接口的返回结构定义好，前端在等待后端联调时就能用Mock数据先渲染页面，效率提升非常明显。如果非要手写Word文档，只要保持上面五个要素齐全、接口路径用@RequestMapping里的值保持一致，也是完全可以的。

5.2 围绕接口文档做自测的三板斧

有文档之后，联调阶段我习惯按这个顺序走：

1. Mock先行：前端不依赖后端启动，先用Apifox生成的Mock数据把列表、表单、详情页面全部跑通，提前发现字段缺失和类型不匹配问题。这一步能把联调期的bug减少一半以上。
2. 接口自测清单：按模块列一张功能测试表，每个接口标注"正常路径、异常路径、边界值"三条用例。比如项目审核接口，正常路径是"学院管理员点击通过后状态变为校级待审"，异常路径是"非学院管理员调用该接口返回无权限"，边界值是"项目当前已结题再次提交审核应返回状态冲突"。
3. 统一响应体规范：所有后端接口返回结构必须是{ code, message, data }三元组，success的判断只看code == 200。这样前端封装Axios时才能写一次拦截逻辑通吃所有接口。如果这个规范在执行中出现偏差——比如某个接口把数据直接塞在顶层而不是data里——联调时就会频繁出现"为什么我的页面是空的"这种定位半小时的问题。

6. 拿到完整源码后的部署步骤与避坑指南

6.1 环境版本搭配：先对齐再动手

一套完整源码能不能顺利跑起来，60%的问题出在环境版本上。我先给出我实测稳定的组合：

版本这块最常翻车的组合是"Node 18+ 跑Vue 2的老项目"，经常在npm install阶段就报node-sass编译错误。遇到这种问题最快的解法是降低Node版本（用nvm管理多版本），或者把node-sass替换成sass并调整版本号。我建议所有拿这个项目的人，先看一眼package.json里的依赖再决定Node版本。

6.2 从导入到跑通的完整流程

后端启动步骤，按顺序执行：

1. 用IDEA导入后端目录，等待Maven下载依赖（务必确认settings.xml里配了阿里云镜像https://maven.aliyun.com/repository/public，否则下载过程会很痛苦）。
2. 本地启动MySQL，用Navicat或命令行执行项目根目录下的database.sql脚本，确认生成数据库和表、初始化数据都正常。执行完随便查一下user表有没有数据，有就说明脚本没问题。
3. 修改后端application.yml中的数据库连接信息：URL、用户名、密码必须和你本机MySQL一致。常见写法如下：

spring: datasource: url: jdbc:mysql://localhost:3306/dachuang?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码

注意serverTimezone=Asia/Shanghai不能省，MySQL 8.0下不加这个参数会报时区错误。

4. 运行启动类DachuangApplication，看到Started DachuangApplication日志说明后端成功。
5. 前端目录打开终端，执行npm install，完成后执行npm run serve，默认地址http://localhost:8081（或项目的configured端口）。

前端跑起来后，用SQL初始化好的管理员账号登录（一般默认admin/admin123或者管理员账号看SQL脚本），进系统逐一点一遍菜单，确认能正常加载列表和数据。

6.3 我实测中遇到的几个典型坑

虽然版本对齐了，实际跑的时候还是有一些隐藏的坑。我挑三个最常见、也是最容易让新手卡壳的来说。

坑一：前后端跨域问题。前端地址是localhost:8081，后端是localhost:8080，浏览器默认会拦截跨域请求。解决办法是在后端写一个跨域配置类实现WebMvcConfigurer的addCorsMappings，允许所有路径和来源。如果发现请求能发出但被浏览器拦截，十有八九是后端漏配了CORS。

坑二：分页查询数据全空但数据库有数据。这种情况大概率是MyBatis Plus分页插件没有配置合法的拦截器。Spring Boot 2.7 + MyBatis Plus有一个经典配置片段：

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

如果没有这段配置，列表接口虽然不报错，但分页结果永远为空，排查起来非常迷惑。

坑三：前端登录后刷新页面就跳回登录页。这是典型的Vue路由守卫加token校验但刷新时用户信息丢失导致的。解决办法是在main.js的初始化流程里，先读本地缓存中的token，再调用一次获取用户信息的接口把用户对象放回Vuex/Pinia，路由守卫判断的"用户是否存在"就不会因为一次刷新而断档。

7. 针对答辩演示的额外准备：让系统看起来真的有业务深度

最后补一段我在演示这套系统前专门做的准备工作，给正在准备答辩的同学直接抄作业。

一是准备一条完整的演示链路。我建议走"学生申报→学院初审→校级立项→中期检查→结题申请"这条主流程。演示时用三个浏览器窗口分别登录三种角色，一个窗口提交，另一个窗口审核，全程不需要重新登录切换账号，流畅度和说服力都拉满。这条链路要求你在SQL里准备一个从"草稿"到"中期检查中"各个状态的项目样本，现场演示状态回退（比如学院驳回并填写理由）的效果也特别好。

二是把接口文档和SQL脚本的重点页面提前截图存好。答辩现场如果网络有问题或电脑突然卡顿，至少还能用截图展示数据库表设计文档、接口测试记录这些"过程性材料"。很多项目的验收标准其实是看你能不能讲清楚"从数据库到接口到页面，一条数据是怎么流动的"，这几张图恰好覆盖了这条链路。

三是准备一页"系统难点"清单。答辩最怕被问"你这个系统有什么难点"，回答"都是CRUD"虽然诚实但没有加分。我从这个项目里提炼了三个可以讲的点：项目状态机的流转设计、审核记录的留痕机制、JWT无状态鉴权方案。每个点配一段代码或一个表结构讲，两三分钟能讲完，都落到了实处。

这套系统做完之后，我自己的体会是：无论功能多少，一个管理系统的骨架从来不是花哨的页面，而是清晰的数据模型、稳定的状态流转和有据可查的接口约定。把这三件事打磨到位，后面不管是往上加功能、换用户角色还是改审批流程，都不会伤筋动骨。希望这篇拆解能帮你把项目吃透，真正做到拿着源码也讲得出门道。