企业官网建设流程全解析

前阵子帮一所高校做了一个大学生创新创业训练计划项目管理系统，也就是大家常说的“大创管理系统”。这系统说白了就是用来管理大学生创新创业训练计划全流程的：学生线上申报项目、指导教师审核、学院推荐、学校审批，再到中期检查、结题验收和成果统计，一条完整的业务闭环。整个项目采用前后端分离架构，后端拿SpringBoot2做基础框架，持久层用MyBatis-Plus简化常规SQL开发，数据库上的是MySQL8.0，前端用Vue3加组合式API完成页面交互，源码结构清晰，配套设计文档也很完整，非常适合拿来学习、二开、甚至直接改吧改吧部署上线。

这篇文章就围绕这套系统，把技术选型的逻辑、核心模块的实现思路、关键业务的流转方式，以及部署上线时容易踩的坑一次说清楚。如果你是准备拿它做毕业设计选题，或者在接高校信息化项目时需要参考一个成熟的业务模型，这篇内容应该能帮你少走不少弯路。我尽量把实操层面的细节都交代到位，包括仓库结构、表设计、请求封装、批量操作、打包部署这些实际开发中绕不开的点。

1. 项目整体设计与技术选型分析

1.1 大创管理系统到底是什么

大创项目全称“大学生创新创业训练计划项目”，是高校常见的实践教学环节，一般分为创新训练项目、创业训练项目和创业实践项目三大类。管理系统要解决的，就是把原本靠纸质材料、QQ群通知、线下跑签字盖章的流程，搬到线上完成。这个系统的业务角色大概能拆成四类：学生、指导教师、学院管理员、校级管理员，部分学校还有评审专家参与立项评审环节。

核心业务模块不外乎这几块：项目申报、项目审核、中期检查、结题验收、经费管理、成果登记和统计报表。每个模块的状态流转都不复杂，但相互穿插之后，工作量就上来了。比如一个学生提交申报书之后，指导老师要审、学院要推荐、学校要复核，不同角色看到的数据范围不一样，操作权限也不一样。系统设计的好坏，很大程度上就体现在这种多角色多状态的权限切分是否清晰。

这套源码里把这些角色和流程都落得很完整。学生端能看到自己的申报记录、审核进度、审批意见，能上传过程材料；管理端可以做批量审核、按学院统计申报数量、导出汇总表。整体上看，它不是一个demo级别的练习项目，而是一个可以直接拿到真实场景里跑的业务系统。

1.2 技术栈选型背后的考虑

为什么用SpringBoot2而不是SpringBoot3？其实主要原因是当前高校和培训生态里，SpringBoot2的资料储备太丰富了。网上随便一搜都是SpringBoot2的集成教程、踩坑笔记、源码解析，遇到稀奇古怪的问题能查到的解决案例也多。虽然说SpringBoot3在性能和响应式编程上更强，但对这种以CRUD为主的业务管理系统来说，稳定性和生态成熟度比新特性更重要。

MyBatis-Plus的引入则是明显冲着开发效率去的。传统MyBatis写一个简单的单表查询都要配XML、写resultMap，创业项目的公共字段、逻辑删除、多表分页这些逻辑还要自己封装。MyBatis-Plus把单表CRUD直接给到BaseMapper，连SQL都不用写，分页插件一配置就完事，开发效率至少提升一倍。当然它也存在一些争议，比如多表关联查询时不如手写XML灵活，但我一直认为工具的选择要看场景。大创管理系统里的绝大多数数据操作，单表查询加上简单的关联即可搞定，这类场景恰好是MyBatis-Plus的主场。

MySQL8.0在这个系统里不是简单当个存储工具，它还承担了一部分数据统计计算的逻辑。窗口函数、JSON类型、公用表表达式CTE，这些特性在处理报销明细、多级审核记录和动态表单数据时能省很多事。前端选Vue3就更直接了：组合式API让代码复用性更强，配合Element Plus做后台管理界面，组件生态成熟，网上的案例也多，团队上手成本很低。

1.3 项目的分层结构拆解

从目录结构上看，这系统是标准的单体分层架构，Maven多模块还是单模块视仓库版本而定，但核心分层思路很一致：

模块边界清楚，Controller层很薄，业务逻辑收敛在Service层，跨表操作通过Service组合完成，这样后面如果需要把报表模块做成独立服务，拆起来也相对容易。还值得说的是，系统里有常规的Result封装类，所有接口返回统一格式包括状态码、消息、数据体，前端对接口返回的拦截处理会变得很统一，不用为个别接口单独写异常判断。

2. 后端核心实现：SpringBoot2与MyBatis-Plus的黄金组合

2.1 通用CRUD服务的搭建思路

大创系统里最常见的操作就是给实体做增删改查。写代码的时候如果每张表都手写一遍Mapper方法，恐怕光项目记录、项目成员、审核记录这三张表就能写几百行重复代码。MyBatis-Plus解决这个问题的思路很直接：BaseMapper提供了一批通用方法，实体类上标注好注解映射，就能直接用selectById、selectPage、insert、updateById完成绝大部分单表操作。

具体落地时，需要给实体类加上表名和主键策略注解。比如项目信息表：

@Data @TableName("t_project") public class Project { @TableId(type = IdType.AUTO) private Long id; private String projectName; private String projectType; private String studentNo; private Long mentorId; private Integer status; @TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; @Version private Integer version; }

这里有两个点我要单独拎出来说。第一，@TableField(fill = ...)配合MetaObjectHandler可以做到插入时自动填充创建时间、修改时间，不需要每个Service里手写setCreateTime(LocalDateTime.now())，既省事又能保证字段是数据库服务器时间还是应用服务器时间的一致性。第二，@Version乐观锁字段用于防止并发修改，比如多个评委同时操作同一份申报书的时候，乐观锁能避免后写覆盖先写的尴尬。

Service层通常是继承ServiceImpl<ProjectMapper, Project>，这样save、updateById、list、page这些方法开箱即用。如果要做稍微复杂一点的条件查询，用LambdaQueryWrapper就能搞定，既有类型安全提示，又不会因为表字段改名连累到查询代码报错。

2.2 批量操作与分页查询的坑与对策

批量操作几乎是管理系统逃不掉的需求。大创系统里典型场景是校级管理员在立项公示之后，需要一次性批准几十个项目进入下一阶段，逐个调用单条更新接口那效率太低了。MyBatis-Plus提供了saveBatch方法，底层是循环执行单条Insert，对大几十条的数据量来说性能完全够用。但如果数据量到了几百上千级别，就需要自定义批量SQL。

一个典型的优化方案是使用@Insert注解配合<script>标签写foreach批量插入，比如批量添加项目成员：

@Insert("<script>" + "INSERT INTO t_project_member(project_id, member_no, member_name) VALUES " + "<foreach collection='list' item='item' separator=','>" + "(#{item.projectId}, #{item.memberNo}, #{item.memberName})" + "</foreach>" + "</script>") int batchInsertMembers(@Param("list") List<ProjectMember> members);

这种批量Insert单条SQL拉满，性能提升非常明显。需要注意MySQL对单条语句的大小有限制，默认max_allowed_packet是4M，如果一次性插入数十万条数据，需要要么分批执行，要么在数据库端调整参数，否则会直接报PacketTooBigException。

分页插件配置里也有一个容易踩的坑。MyBatis-Plus的分页插件PaginationInnerInterceptor在旧版本里默认支持单页查询，但新版本里必须显式指定maxLimit。在我实际配置的时候是这样处理的：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); PaginationInnerInterceptor pageInterceptor = new PaginationInnerInterceptor(DbType.MYSQL); pageInterceptor.setMaxLimit(500L); pageInterceptor.setOverflow(false); interceptor.addInnerInterceptor(pageInterceptor); return interceptor; }

setMaxLimit(500L)是防止恶意调用方把pageSize拉到10万，直接把数据库打死。setOverflow(false)控制页码超出总页数时是否回正到最后一页，这个看业务需求，查询类接口建议设为false做容错。

2.3 代码生成器：不是锦上添花，是必备

大创系统里实体类、Mapper、Service、Controller加起来几十个文件，纯手写工作量太大，而且写完Mapper接口忘了加@Mapper注解这种低级错误很容易出现。MyBatis-Plus的代码生成器组件能根据表结构直接生成全套CRUD代码，虽然生成的代码不能直接用于生产，但骨架搭好了，后面填充自定义业务逻辑就省了多一半的力气。

我一般把生成器写成一个独立的测试类，每次新增数据库表时跑一遍。重点关注几个配置项：

• url、username、password写数据库连接信息；
• strategy.setInclude()指定本次要生成哪几张表；
• superEntityColumns排除公共字段，避免代码里重复生成id、createTime、updateTime；
• entity.setLombokModel(true)让生成实体带@Data注解；
• controller.setRestControllerStyle(true)生成@RestController风格的控制器。

生成完之后，还有两个步骤不能省略。一是检查实体类型映射，比如datetime类型默认生成LocalDateTime，decimal生成BigDecimal，如果数据库字段类型建得不规范就可能映射成预期之外的Java类型。二是给生成的ServiceImpl里剔除掉那些冗余的空实现方法，保留实际需要覆盖的场景，这样代码里面不会堆一堆空壳子。

3. 前端工程化：Vue3组合式API后台管理框架的实践

3.1 Vue3项目初始化与工程结构规划

这个项目的前端使用Vue3，配合Vite作为构建工具，比老旧的Vue CLI那一套要轻快不少。初始化的命令很简单：

npm create vite@latest project-admin -- --template vue cd project-admin npm install

新项目装完后，我一般先把目录结构理清楚。按功能划分的目录比按类型划分的目录更利于后期维护：

src/ ├── api/ # 接口请求封装，按业务模块拆文件 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── layout/ # 布局组件，侧边栏、导航栏 ├── router/ # 路由配置与守卫 ├── store/ # Pinia状态管理 ├── utils/ # 工具函数，request请求封装等 ├── views/ # 页面组件，与路由一一对应

实际开发中我强烈建议每个业务模块的API、类型定义、页面组件靠在一起维护，不要一个api文件夹塞几百个文件。大创管理系统这种规模，按模块拆是最舒服的，比如project模块下放api/project.js、views/project/相关页面，找代码很方便。

3.2 组合式API和请求封装的核心技巧

Vue3用组合式API写业务逻辑，最大的变化是逻辑关注点不再被强制拆到data、methods、watch里，而是可以按业务功能组织。比如项目的申报列表页，相关逻辑可以拆成一个useProjectList组合函数，页面组件里只需要调用它就行。

// useProjectList.js export function useProjectList() { const loading = ref(false) const list = ref([]) const total = ref(0) const queryParams = reactive({ pageNum: 1, pageSize: 10, projectName: '', status: '' }) async function fetchList() { loading.value = true try { const res = await listProjects(queryParams) list.value = res.records total.value = res.total } finally { loading.value = false } } function handleSearch() { queryParams.pageNum = 1 fetchList() } onMounted(fetchList) return { loading, list, total, queryParams, handleSearch, fetchList } }

请求封装是前端所有模块的生命线。我习惯用axios建一个统一实例，设置基础URL和超时时间，然后通过拦截器统一处理token注入、错误提示、用户登录失效跳转：

const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response?.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.response?.data?.message || '网络异常') return Promise.reject(error) } )

这里有个设计细节说一下：后端返回的统一结构是{ code, message, data }，给前端页面使用时，拦截器里直接返回res.data，这样页面上拿到的数据就是业务数据本身，不用每个页面再判断一次code !== 200，逻辑清爽很多。

3.3 权限控制与动态路由的处理方式

后台管理系统的权限控制不能只在后端做，前端一定要配合。后端通过Spring Security或者拦截器控制接口访问权限，前端则需要根据当前用户的角色，动态生成可见的菜单和可进入的路由。这套系统里，不同角色登录后看到的导航结构完全不同：学生看到“我的项目”“项目申报”“中期报告”，管理员看到“项目审批”“统计报表”“用户管理”。

实现上采用动态路由方案。用户登录后，先请求后端获取当前用户的角色和权限码，前端根据这个信息再拼接路由表，而不是把所有路由一次性注册。这里有个注意点：刷新页面时Vue Router已经初始化，动态路由必须在路由守卫里判断store里是否有路由信息，如果为空就重新加载并router.addRoute()，否则刷新后页面直接404。

按钮级别的权限我一般自定义一个指令比较方便：

app.directive('permission', { mounted(el, binding) { const required = binding.value const has = useUserStore().permissions.includes(required) if (!has) { el.parentNode?.removeChild(el) } } })

这样页面里就能直接通过v-permission="'project:approve'"控制按钮是否渲染，后端的接口权限校验也不能少，这里的控制只是优化体验，不能作为安全边界。

4. 数据库设计与MySQL8.0的实战应用

4.1 核心表结构设计与业务建模

表结构设计直接决定后续业务流程好不好写。大创系统的核心表我总结下来大概有这么几张：

设计时要注意几个关键点。第一，项目当前状态status是冗余存储还是实时计算？我的做法是冗余，因为业务流程里经常需要按状态筛选列表，比如学生要看“已立项”的项目，如果每次都通过关联审核记录来推导状态，查询成本太高。冗余状态字段配合状态机校验，确保项目状态流转只能沿合法路径走，比如申报中到审核中，不能直接从申报中跳到已结题。

第二，审核记录表t_approval一定要保留完整的审核链路。大创项目可能存在学院初审、学校终审两级审核，审核意见必须能区分是哪个层级哪个审核人给出的。用level字段区分审核层级，用opinion保存审核意见，用approve_time记录操作时间，最后还要把“当前项目最新状态快照”存到项目表里，这样列表查询不需要聚合历史记录。

4.2 MySQL8.0特性在系统中的应用

MySQL8.0对比5.7带来的最大变化之一是窗口函数和CTE。在大创系统里，统计报表模块需要算各学院的项目数量、通过率、每个指导老师名下项目数。用传统GROUP BY也能写，但要算“每个学院项目数量的排名”就得嵌套子查询，写了SQL自己也未必一眼看得懂。用窗口函数就简单直接：

SELECT dept_name, COUNT(*) AS project_count, RANK() OVER (ORDER BY COUNT(*) DESC) AS rank_no FROM t_project GROUP BY dept_name;

还有一个非常实用的点：JSON类型字段在大创系统的应用。创业项目的商业模式、创新点的申报内容，字段长度不固定，结构还可能随年份调整，用JSON存比较灵活。比如项目成员里的分工说明、动态扩展的字段都可以放JSON里。MySQL8.0提供了JSON_EXTRACT、JSON_CONTAINS等函数，查询也能跟着灵活起来。

不过JSON字段也不是银弹，有两点要在设计评审时就讨论清楚。其一，JSON字段不能建常规索引，如果高频查询条件藏在JSON里，性能就会出现瓶颈；其二，数据库JSON中的约束校验能力很弱，写进去的是不是符合业务语义，只能在应用层把关。大创系统的做法很合理：核心字段（项目名称、状态、类型、负责人）全部用普通列冗余存储，辅助细节信息放JSON，查询和灵活性兼顾。

4.3 Docker方式快速部署MySQL8.0

如果要在本地复现这套系统，数据库环境是第一个门槛。直接安装MySQL8.0原生版也能行，但我在不同机器上踩过版本不兼容的坑，所以更推荐Docker部署，快速干净还不污染系统环境。

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -e MYSQL_DATABASE=dcms \ -v /opt/mysql-data:/var/lib/mysql \ mysql:8.0 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_unicode_ci

有几个细节需要刻意处理。第一，utf8mb4字符集必须显式指定，否则默认字符集对中文和处理特殊符号都不友好；第二，数据目录要挂载到宿主机，容器删除后数据不丢；第三，生产环境下要把root密码换成强密码，并且创建独立的业务账号，用最小权限连接到业务库。如果你不需要远程连接，记得不要暴露3306端口到公网，本地开发另说。

连接数据库后，执行项目附带的sql脚本创建表结构。大创系统源码里一般会附一个初始化脚本，包含完整的建表语句和初始管理员的INSERT语句。导入完成后，建议先用一个简单的SELECT确认一下关键表数据是否正确，别等程序启动失败才回过来排查。

5. 核心业务流程梳理：从申报到结题的全周期

5.1 项目申报的流程与数据流转

学生在系统里发起项目申报，要先填写项目基本信息，包括项目名称、项目类型、项目简介、预期成果、经费预算等。前端页面提交后，后端接收数据的逻辑是：先把项目主记录插入t_project，状态设为申报中，然后插入项目成员记录，关联当前登录学生的学号，再创建一条待审核的初始审核记录。这三个操作必须放在同一个事务里，任一步失败都要回滚，否则会出现有主记录没有成员记录的半成品数据。

这里有一个我自己踩过坑的细节：前端传递项目成员时，一定要校验成员数量。按大创项目的规则，项目组成员通常限定在2到5人，且成员不能重复出现。校验逻辑不能只靠前端，后端在Service层必须再做一次，不然绕过前端发POST请求就能造出非法数据。简单做法就是遍历成员列表，用Set去重再做数量判断。

申报提交后，项目的状态流转就开始运转。前端菜单里的“我的项目”页面，会展示每个项目的当前状态、审核意见、当前办理人。后端查询项目列表时，根据当前用户的角色过滤数据范围：学生只能看自己参与的项目，学院管理员只能看本院的项目，校管理员可以看全校项目。

5.2 指导老师审核与院系推荐环节

指导老师登录后看到的是待自己审核的项目列表。审核操作十分明确：通过或不通过，必须填写审核意见。这里有一个有意思的业务细节，指导老师的审核意见在大部分高校是要求必须填写的，不能直接点通过，后端的校验逻辑也要同步实现，否则在管理过程中会被质疑系统设计不严谨。

学院管理员的推荐环节则更复杂一些。学院管理员需要在“指导老师已通过”的项目中，根据名额和排序规则，选择推荐到校级评审。排序逻辑通常用评审得分，这时需要区分两种分数：导师评分和学院评审评分。系统里这两个分数分别存在审核记录的不同字段，或者分两条审核记录存储，重点在于统计时不能搞混。

到了校级管理员审批环节，系统需要提供批量审批的效率工具。校级管理员面对的可能是一百多个项目，逐个点开审核效率太低了。系统里做成勾选表格加批量审批按钮，选中多个项目后统一设置为“校级立项”状态。批量操作在后端的实现就是文章第二节提到的自定义批量更新SQL，或者循环调用updateById，要注意的是一次事务里批量更新十几条甚至几十条的性能问题不大，但如果有几千条就需要分批次提交事务。

5.3 中期检查与结题验收

项目立项之后，并不是放着不管等到结题。大学生创新创业项目通常运行周期是一年，中期检查是重要节点。系统里要设置中期检查提醒，最好能提前一周给项目负责人生成待办记录。

中期检查的核心是项目进度报告。学生提交当前进度、阶段成果、经费使用明细，指导老师给出检查结论。比较常见的业务逻辑是：如果进度低于某个阈值，系统可以建议管理员给项目发警告或调整经费。这些规则可以在配置表维护，不写死在代码里。

结题验收的流程与中期检查类似，但多了一个成果材料收集环节。学生需要上传结题报告、论文、专利、实物照片等附件，上传的附件往往不止一个，需要支持多文件批量上传。后端用腾讯COS、阿里OSS或MinIO保存文件，大创系统数据量不大，MinIO或服务器本地上传目录就够了。前端用el-upload设置multiple属性，提交时按项目ID关联存储附件记录即可。

结题之后，项目进入成果库，学校管理员可以按学院、按年份统计结题率、优秀率，生成年报材料。数据的统计报表用ECharts做图表展示，后端SQL用聚合函数加窗口函数汇总，才能支撑指标的灵活筛选。

6. 部署上线与常见问题排查实录

6.1 前后端打包部署的两种推荐方案

这套系统在高校里部署，最常见的方式是前后端分开部署，不搞K8s那套复杂架构，直接一台服务器搞定。前端打出来的静态文件由Nginx托管，后端打成Jar包通过systemd服务托管。

前端构建命令是：

npm run build

构建完成后，dist目录下就是纯静态文件，复制到Nginx的html目录。Nginx的配置需要注意两个核心点：一是前端路由用history模式时，必须配置try_files，刷新404的问题才能解决；二是/api开头的请求反向代理到后端服务，避免跨域问题。参考配置如下：

server { listen 80; server_name your.domain.com; client_max_body_size 100m; location / { root /opt/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

后端打包前要注意application.yml里的数据库连接、Redis地址（如果用到）必须改成生产环境信息。执行：

mvn clean package -DskipTests

生成dcms-server.jar后放到服务器上运行，用systemd写一个服务单元文件，支持开机自启和崩溃自动拉起。

6.2 部署与开发过程中的典型问题速查

实际操作过程中，我遇到了不少问题，这里整理了一个速查表，每一个都是实际踩过的坑：

6.3 如何高效使用项目附带的设计文档

这套源码比较好的地方是附带文档。文档里面通常会包含数据库设计说明、接口文档、部署手册和部分测试用例说明。不同角色的读者应按照不同顺序来读。

如果你是想快速把项目跑起来，我的建议是只看部署手册和初始化说明，先把数据库初始化、后端启动、前端启动三步做好，系统能跑通后再去研究具体代码逻辑。跑通之后，你就会对整个系统的数据流有最直观的认识，此时再回头看表和接口，效率会高很多。

如果你是想搞清楚某个业务功能的实现细节，比如“立项审核的流程到底是怎么写的”，直接搜索审核状态相关的接口，顺着Controller到Service再到Mapper一层层往下走。项目本身模块边界清楚，一个垂直业务的代码大概率都集中在前后端各一个模块下，定位成本不算高。

如果你是打算拿这个项目改成毕业设计，最需要重点看的是数据库设计文档和核心业务的状态机设计，这两个东西是一个管理系统的灵魂。把状态流转的算法逻辑理解透，答辩的时候老师问业务相关的问题就能对答如流。

我的实操心得与后续扩展建议

这套系统跑下来，我最大的感受是：大创管理系统这类“业务驱动型”项目，真正的难点不在某个单一技术点，而在把多角色、多流程、多状态转换这个复杂的业务模型理顺，并且用工程化的手段管理起来。SpringBoot2和Vue3这套组合，单看每一项都不算高深，但结合在一起能形成一套稳定、高效、易维护的全栈解决方案。MyBatis-Plus大幅度降低了数据库层的重复劳动，Vue3的组合式API让前端逻辑的复用和梳理都轻松了很多，MySQL8.0的窗口函数和JSON支持又为统计报表和灵活扩展留下了空间。

最后再说一个小技巧。部署前记得把后端日志级别调成INFO，不要用DEBUG，不然启动后ECharts统计报表接口的SQL日志会把日志文件撑爆。还有一点，项目里的密码加密方式我建议默认用BCryptPasswordEncoder，不要用明文。虽然大创系统不是强攻击目标，但高校系统一旦数据泄露，牵扯的是几百上千个学生的个人信息，这个底线值得守住。