企业官网建设流程全解析

最近在整理手头这套前后端分离的Web本科生交流培养管理平台系统，从最开始梳理业务模型，到用SpringBoot+Vue+MyBatis+MySQL这套技术栈把项目完整落地，再到后期部署和排错，整个过程差不多持续了一个多月。现在源码完整、部署流程也验证过好几轮了，我把整个项目的设计思路、核心实现和部署细节整理成这篇文字，方便正在做类似毕设或课程设计，以及想系统学习前后端分离项目实战的开发者直接参考。

这套交流培养管理平台面向本科生培养过程中最日常的几个场景：培养计划发布、导师双选、学术交流答疑、课题申报和成果归档。系统里分学生、教师、管理员三类角色，前端用Vue负责页面与交互，后端用SpringBoot提供RESTful接口，MyBatis作为持久层框架操作MySQL数据库。如果你已经掌握了一些Java和Vue的基础，但缺少一个完整的项目串联经验，这篇文章值得一步步跟下来。

1. 为什么需要这样一套交流培养管理平台：业务痛点和系统定位

1.1 本科生培养过程的真实管理困境

很多高校的本科生培养管理，实际推进过程中非常依赖人工。教学秘书用Excel收集培养计划，导师分配靠纸质志愿表线下统计，学生遇到学术问题只能课下找老师或在年级大群里问，有价值的问答内容没有沉淀，下届学生照样重复踩坑。课题申报、结题验收、成果登记这些环节更是散落在各个系统甚至微信聊天记录里。

这些碎片化操作的直接后果，是管理成本高、追踪困难、数据不连贯。比如导师带的学生有几次指导记录、学生提交过哪些培养材料、某个课题的申报进度到了哪一步，信息散落各处就无法快速给出结论。我在设计这套系统时，核心出发点就是把这些分散的流程收拢到一个平台上，让培养过程从"无记录"变成"有迹可循"，从"靠人催"变成"线上流转"。

1.2 学生、教师、管理员三类角色的业务闭环

交流培养管理平台天然是一个多角色协作系统，我梳理下来核心角色和诉求如下表所示：

整个业务闭环的逻辑是：管理员和教师先行维护培养计划与课题资源，学生进入系统后查看计划、选择导师、参与学术交流，同时在平台上申报课题、提交成果，教师对学生的申请和成果进行审核反馈，管理员通过后台数据掌握整体运行状态。这个闭环覆盖了本科生从入学到毕业过程中最常接触的管理环节，也是我后面拆解模块和设计数据库的依据。

1.3 功能模块如何划分

根据上面的业务闭环，我把系统拆成了六个主要模块：

• 用户认证与权限管理：登录、注册、JWT鉴权、基于角色的菜单权限控制。
• 培养计划管理：教师或管理员发布学期培养计划，学生按学期查看计划明细。
• 导师双选管理：教师发布招生名额，学生提交志愿，教师确认或拒绝。
• 学术交流社区：学生和教师发帖、回帖、分类浏览，支持关键词检索。
• 课题申报与成果管理：教师发布课题，学生申报，结题后登记论文、竞赛等成果。
• 数据统计与消息中心：首页展示培养概况，站内消息推送关键审核状态变化。

模块之间的数据是共享的，比如用户模块的ID贯穿所有业务表，课题申报完成后自动生成一条待审核消息，成果登记后又可以反哺统计报表。这个逻辑理顺了，后面无论是建表还是写接口，思路都会清楚很多。

2. 技术选型思路：为什么偏偏是SpringBoot+Vue+MyBatis+MySQL这一套

2.1 前后端分离结构的核心收益

把前端和后端拆成两个独立工程，很多人第一反应是"部署变复杂了"。但从实际开发体验看，前后端分离带来的收益远大于成本。

首先是职责边界清晰。前端团队或开发者只需要关注页面结构、交互逻辑和接口调用，后端只需把接口契约定清楚，不需要操心页面渲染。其次是开发调试效率高，前端用Vue dev server跑在本地，后端用Spring Boot内嵌Tomcat跑在另一个端口，两者通过HTTP通信，前端数据异常可以直接定位是接口问题还是渲染问题。这套系统里我使用的就是标准前后端分离结构，前端工程只做页面展示和状态管理，后端只提供JSON数据接口，不包含任何视图页面。

2.2 后端选型：SpringBoot快速搭建，MyBatis控制SQL

SpringBoot是目前Java后端开发绕不开的框架。选它不是因为"流行"，而是因为它确实能减少大量基础设施配置。内嵌Tomcat、自动配置注入、Starter简化依赖管理，意味着一个新项目搭起来只需要一个启动类加少量配置。对于这种管理系统，SpringBoot的生态也非常成熟，集成MyBatis、JWT、文件上传等都有一大堆现成方案可以少走弯路。

MyBatis在这套系统里承担的是持久层访问。它和SpringBoot的整合非常顺滑，mybatis-spring-boot-starter加进去后，只需要定义Mapper接口和XML文件。相比JPA的全自动映射，我更喜欢MyBatis的点在于SQL完全可控，尤其是多表关联查询、分页SQL、动态条件拼接这些场景，自己写SQL心里更有底。另外系统里有一些复杂统计SQL，比如按导师维度统计指导学生数量、按学期统计计划完成率，这种场景MyBatis的优势非常明显。

2.3 前端选型：Vue的渐进式开发体验和组件生态

前端我选的是Vue，配合Vue Router做路由、Vuex做状态管理、Axios做HTTP请求。Vue的学习曲线相对平缓，模板语法直观，特别适合逻辑并不复杂的后台管理系统。组件化开发带来的好处是把页面拆成一个个可复用组件，比如用户列表、分页器、表单弹窗，写成组件后不同页面直接引用，代码量能少不少。

对这套系统来说，我在页面布局上引入了Element UI组件库，表格、表单、对话框、消息提示这些基础控件不用自己造轮子。选择Vue 2版本是从稳定性和生态兼容性考虑的，因为Element UI对Vue 2的支持最成熟，网上资料也最多，遇到问题基本都能搜到解决方案。如果你已经在用Vue 3和Element Plus，核心思路完全一样，只是API细节上有些区别。

2.4 MySQL为什么够用且稳定

MySQL在这套系统里承担所有结构化数据的持久化存储。本科生培养管理系统的数据量级别，在单表几万到十几万条的规模下，MySQL配合合理索引和分页查询完全可以轻松应对。MySQL 5.7和8.0都支持事务、存储过程、视图等能力，更重要的是它对Linux和Windows环境都友好，安装和运维成本低。实际部署时我建议数据库字符集使用utf8mb4，因为交流社区里学生可能发表情符号，utf8mb4才能完整支持。

这套技术栈组合在一起，最终效果就是一个典型的"低门槛、高稳定性、资料丰富"的项目体系。对做毕设或课程设计的同学来说，这套组合在答辩时也非常容易讲清楚：SpringBoot负责什么、Vue负责什么、MyBatis如何访问MySQL，每个环节都边界清晰，评委问起来完全不慌。

3. 数据库设计：把培养管理业务翻译成表结构

3.1 核心表结构和职责说明

这套系统的数据库我设计为一张用户中心表加六类业务表。下面先列一个整体清单：

sys_user是所有业务表的锚点，通过user_id或student_id字段把操作者和数据关联起来。比如学生发帖，topic_post.user_id指向sys_user.id；学生申请导师，tutor_selection.student_id和teacher_id都指向sys_user.id，通过角色类型区分身份。这种设计的好处是用户体系单一，权限控制维度清晰，出现问题也容易追溯。

3.2 表间关系设计的几个关键取舍

在设计表关系时，我专门并列了几个关键点：

• 逻辑外键优于物理外键。业务表里虽然存在大量关联字段，比如tutor_selection.student_id参照sys_user.id，但我没有在数据库层面加物理外键约束。原因是业务系统里删除用户、批量导入数据时，物理外键的强约束会导致很多操作无法灵活执行。维护逻辑外键配合代码层校验，实际使用中更稳妥。
• 状态字段贯穿所有流程表。训练计划、导师双选、课题申报这些表都有status字段，用数字表示不同状态（0待处理、1通过、2驳回），所有状态流转都通过后端接口控制，禁止前端直接改状态。
• 时间字段统一格式。所有表的创建时间和更新时间统一用datetime类型，业务上的时间节点（比如选导师截止时间）单独用date或datetime字段存储，避免语义混乱。
• 大字段拆分。交流帖子的正文content用text类型存储，列表展示时只查询摘要和标题，详情页再加载完整内容。这样列表SQL的IO压力明显更小。

3.3 设计中容易被忽略的索引和初始化数据

建表时我的习惯是为所有外键字段、状态字段和查询频率高的字段建立索引。比如topic_post的category、training_plan的semester、tutor_selection的teacher_id和status，这些字段经常作为WHERE条件或GROUP BY字段出现，没有索引的话数据量上来之后分页查询会明显变慢。另外mysql的联合索引在设计中也用上了，比如tutor_selection表建了(student_id, status)的联合索引，查询某个学生的申请记录只需要走一个索引。

初始化数据是另一个容易被忽略的点。上线前我把管理员账号、默认角色数据、几个测试教师和学生账号直接写进了初始化SQL脚本。管理员账号固定为admin，初始密码经过BCrypt加密存入，首次登录后可以修改。开发调试阶段直接使用这些账号省去注册流程，部署阶段也方便快速验证系统是否正常。

4. SpringBoot后端核心实现：分层架构与关键代码

4.1 工程结构与分层设计

后端工程我采用的是经典的三层架构：Controller接收请求并做参数校验，Service处理业务逻辑，Mapper负责数据访问。实际目录结构如下：

src/main/java/com/example/cultivation/ ├── controller/ # 接口层 ├── service/ │ ├── impl/ # 业务实现 ├── mapper/ # MyBatis Mapper接口 ├── entity/ # 数据库实体类 ├── dto/ # 请求与响应对象 ├── vo/ # 视图对象 ├── config/ # 配置类（CORS、JWT拦截器、MyBatis配置） ├── common/ # 统一响应、异常处理、工具类 ├── utils/ # JWT、日期等工具 └── CultivationApplication.java

这个分层的必要性在维护阶段体会特别深。比如要给导师双选功能增加一个"不能重复申请"的校验，只需要在Service层加一段逻辑，Controller和Mapper完全不用动。不同层各司其职，项目规模变大后依然不会乱。

4.2 统一响应封装与全局异常处理

前后端分离项目最重要的一点是接口返回结构一致。我这里封装了一个Result类，所有接口都返回同一结构：

@Data public class Result<T> { private Integer code; // 200成功，500业务异常，401未登录 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } public static <T> Result<T> unauthorized(String message) { Result<T> result = new Result<>(); result.setCode(401); result.setMessage(message); return result; } }

配合全局异常处理器，把校验异常、业务异常和兜底异常统一转换为Result返回。这样前端Axios拦截器只需要判断code是否为200，够简洁。

关键接口格式统一后，前端封装Ajax请求也变得非常舒服，后续新页面接入接口就只是一次简单的Post调用。

4.3 JWT登录认证与角色权限控制

登录认证我使用的是JWT方案。用户传入用户名密码后，后端校验BCrypt加密后的密码是否匹配，匹配则使用JJWT生成一个token，token中携带userId、username、roleType和过期时间，响应给前端。前端在请求头带上Authorization字段：

// JWT工具类核心方法 public String generateToken(Integer userId, String username, String roleType) { Date now = new Date(); Date expireDate = new Date(now.getTime() + 7 * 24 * 60 * 60 * 1000); return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("roleType", roleType) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }

在后端使用拦截器统一验证token，并解析出用户信息放入ThreadLocal供Service层调用。没有token或token过期的请求直接返回401。角色权限上我在拦截器里做了一个简单的注解控制思路：管理员专用的接口检查当前用户角色是否为admin，普通用户接口只判断是否登录。这套轻量级鉴权对毕设和中小型系统已经足够，不需要引入Spring Security那种重框架。

4.4 MyBatis Mapper与XML中的关键写法

MyBatis是本系统的数据访问核心，实际开发中我大量使用了动态SQL和关联查询。下面这段是交流帖子分页查询的Mapper XML，展示了动态条件拼接的典型写法：

<select id="selectPostPage" resultType="com.example.cultivation.vo.TopicPostVO"> SELECT tp.id, tp.title, tp.category, tp.view_count, tp.reply_count, tp.create_time, su.real_name AS authorName FROM topic_post tp LEFT JOIN sys_user su ON tp.user_id = su.id <where> <if test="category != null and category != ''"> AND tp.category = #{category} </if> <if test="keyword != null and keyword != ''"> AND (tp.title LIKE CONCAT('%', #{keyword}, '%') OR tp.content LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY tp.create_time DESC LIMIT #{offset}, #{pageSize} </select>

动态SQL配合LIKE查询完成帖子的分类过滤和关键词搜索，LEFT JOIN一次性把发帖人的真实姓名带出来，避免前台二次查询。这里有一个我强调过的细节：MyBatis的驼峰映射要在application.yml里开启map-underscore-to-camel-case=true，不然数据库的下划线字段无法自动映射到Java实体类的驼峰属性。

4.5 核心业务接口清单与一个完整接口流程

我整理了这套系统最核心的几个接口，方便你对照理解后端职责：

以导师双选为例，完整流程是这样的：学生提交apply请求，Controller校验参数后调用Service，Service先查tutor_selection表判断该学生是否已经申请过（防重复），然后插入一条status为0的申请记录，同时写一条通知给对应的教师，教师端看到申请后可confirm或reject。整个流程涉及两张表写入和一次状态更新，这里我用@Transactional保证了事务一致性。这块是后端业务逻辑里最有代表性的部分，也是答辩时最值得展开讲的地方。

5. Vue前端实现：路由、请求封装和核心页面

5.1 前端工程目录规划

前端工程基于Vue CLI搭建，目录规划我尽量贴近真实项目习惯。views目录按模块分文件夹，api目录统一存放接口调用文件，router目录单独管理路由表：

src/ ├── api/ # 所有接口请求封装 ├── router/index.js # 路由配置 ├── store/ # Vuex状态管理 ├── views/ │ ├── login/ # 登录页面 │ ├── dashboard/ # 首页仪表盘 │ ├── training/ # 培养计划 │ ├── tutor/ # 导师双选 │ ├── community/ # 学术交流 │ ├── project/ # 课题申报 │ ├── achievement/ # 成果管理 │ └── system/ # 后台管理（用户、角色） ├── components/ ├── utils/request.js # Axios实例封装 └── layout/ # 整体布局组件

这种目录结构把每个业务模块的页面放到同一个文件夹，后续维护时定位代码非常快。组件目录下放一些通用组件，比如分页组件、富文本编辑器封装、图片上传组件，多个页面复用。

5.2 路由配置与导航守卫

前端路由的核心是区分哪些页面需要登录，哪些页面只允许特定角色访问。我在路由配置里给每个页面绑定了meta信息，包含requiresAuth和roles数组：

const routes = [ { path: '/login', component: Login, meta: { title: '登录' } }, { path: '/', component: Layout, redirect: '/dashboard', children: [ { path: 'dashboard', component: Dashboard, meta: { title: '首页', requiresAuth: true } }, { path: 'training', component: TrainingList, meta: { title: '培养计划', requiresAuth: true } }, { path: 'community', component: CommunityList, meta: { title: '学术交流', requiresAuth: true } }, { path: 'system/users', component: UserManage, meta: { title: '用户管理', requiresAuth: true, roles: ['admin'] } } ] } ]

导航守卫在路由跳转前检查token是否存在，以及角色是否满足页面要求。这个机制保证了用户只能通过登录进入系统，管理员页面也不会被普通学生看到，前后端双重校验的思路也在这里体现。前端守卫更多是体验优化，真正安全的还是后端拦截器。

5.3 Axios请求封装与拦截器

所有HTTP请求我统一封装在一个request.js中，基于Axios创建实例。请求拦截器负责在每次请求前把JWT token拼到请求头，响应拦截器统一处理返回码：code为200直接返回数据，code为401则清除本地token并跳转登录页，code为500弹出错误提示。

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }, error => Promise.reject(error)) service.interceptors.response.use(response => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求失败') if (res.code === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error('网络异常，请稍后再试') return Promise.reject(error) })

这个封装看似简单，但实用性很强。项目跑起来之后，几乎不需要再在每个页面里重复处理错误码和未登录跳转了，这也是所有前端页面代码保持清爽的基础。

5.4 核心页面实现：以学术交流社区为例

学术交流模块是整个系统里前端逻辑最复杂的页面之一。列表页使用Element UI的el-table展示帖子标题、分类、作者和回复数，顶部加搜索框和分类筛选器。点击标题跳转到详情页，详情页加载完整帖子和所有回复列表，底部有回复输入框和提交按钮。

实现时要注意的一个细节是页面跳转传参方式。列表页跳详情页我用路由参数传帖子的id：this.$router.push({ path: '/community/detail', query: { id: row.id } })，详情页在created钩子里通过this.$route.query.id拉取详情接口。帖子发布按钮在表单校验通过后调用publish接口，成功后清空表单并重新加载列表。

这套交互流程在培养计划、课题申报等模块中几乎可以复用，前端页面的开发效率很大程度就是从这些可复用的模式中来的。还有一个体会是Element UI表格组件自带的分页配合后端LIMIT分页接口是固定搭配，几乎不需要自己写分页逻辑。

6. 从零到一：完整部署步骤与联调验证

6.1 本地环境准备清单

部署这套系统所需的基础环境如下表。我建议严格按版本准备，版本差异往往是很多奇怪报错的根源：

JDK和Node.js的安装属于常规操作，不多展开。Maven建议在settings.xml里配置阿里云镜像，不然第一次拉依赖会等得让人怀疑人生。Node依赖安装也建议通过npm或pnpm使用国内镜像，节省时间很有效果。

6.2 初始化数据库与基础数据

首先在MySQL中创建数据库，字符集必须指定utf8mb4：

CREATE DATABASE cultivation_system DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;

然后导入项目中的init.sql文件，里面包含建表语句和初始数据。导入完成后可以验证一下基础数据是否正确：执行SELECT * FROM sys_user，应该能看到名为admin的管理员账号，以及其他测试账号。

在使用MySQL 8.0时有一个容易踩的坑是时区问题，连接串上必须加上serverTimezone=Asia/Shanghai参数，否则连接会报错。原因很简单，MySQL 8.0默认时区设置和国内环境不一致，JDBC连接时两边对不上就直接抛异常了。这个问题我后面踩坑章节还会再提。

6.3 后端启动步骤

后端启动前需要检查application.yml中的数据库连接配置，把用户名密码改为自己本地的MySQL账号：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/cultivation_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true

如果是在IDEA里运行，直接启动CultivationApplication主类即可。如果命令行运行，先执行mvn clean package -DskipTests打包成jar，再执行java -jar target/cultivation-system-1.0.0.jar。启动日志出现"Started CultivationApplication"就说明后端成功起来了，此时在浏览器访问http://localhost:8080/api/auth/info应该会返回未授权的JSON提示。

6.4 前端启动步骤

进入前端项目目录，先安装依赖：

npm install

依赖安装完成后启动开发服务器。这里有一个关键问题：Vue CLI默认端口是8080，和后端Tomcat冲突。我的做法是在vue.config.js里把前端端口改为8081，同时配置开发代理，把所有/api开头的请求代理到后端8080端口：

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

配置完成后执行npm run dev，浏览器访问http://localhost:8081，输入管理员的账号密码即可登录系统。我特意使用代理而不是直接写后端地址，是为了避免开发阶段频繁手动修改请求地址，而且代理还能顺便解决跨域问题。

6.5 前后端联调验证清单

系统启动后，建议按下面的清单做一轮完整的功能验证：

• 使用admin账号登录，检查首页统计数据是否正常返回。
• 进入用户管理，确认能查询出学生和教师账号列表。
• 使用教师账号创建一个培养计划，切换到学生账号查看该计划是否可见。
• 学生账号提交导师申请，教师账号确认申请，状态流转是否正确。
• 在学术交流模块发帖、回帖，贴子里能否正常显示作者姓名。
• 学生账号申报课题，教师账号审核通过，通知消息是否到达。

这一轮验证跑完，说明数据库初始化、后端接口、前端页面三条链路已经全部打通，整个系统的核心闭环是健康的。

7. 实战过程中踩过的坑和我的处理方法

7.1 跨域问题：开发与部署的不同解法

前后端分离项目遇到的第一个问题就是跨域。前端跑在8081，后端跑在8080，浏览器直接请求后端接口会被CORS策略拦截。我的处理是开发环境使用Vue CLI的proxy代理，让浏览器的请求同源到前端，由开发服务器转发到后端，绕开跨域限制。部署时如果前后端使用不同域名或端口，则需要在后端加CORS全局配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(Registry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

一个容易忽略的细节是，如果跨域配置里同时设置了allowedOriginPatterns("*")和allowCredentials(true)，某些浏览器会拒绝携带凭证的跨域请求，需要注意allowedOrigins不能直接使用通配符加credentials的组合，这也是网上讨论较多的问题。

7.2 MyBatis参数映射和空值处理的坑

MyBatis在使用过程中最常见的报错就是参数绑定失败和结果映射不完整。参数绑定失败通常是Mapper接口方法参数和XML里的#{paramName}不一致造成的。解决方案有两个：要么在Mapper接口参数使用@Param注解明确命名，要么在编译参数中加上-parameters参数让编译器保留参数名。我现在统一使用@Param注解，简单直观。

结果映射不完整则多数是驼峰映射未开启。数据库字段create_time，Java实体属性createTime，如果不开启map-underscore-to-camel-case，返回值里createTime就是null。排查这类问题时，最快的办法是把MyBatis的SQL日志打开，看SQL执行结果与返回实体是否对得上。

7.3 时间字段的时区与格式化问题

系统里涉及大量的创建时间和截止时间。MySQL的datetime字段默认不带时区信息，如果连接串没有加serverTimezone=Asia/Shanghai，Java侧拿到的时间会和本地时间相差8小时，页面上的日期显示就会"漂移"。更麻烦的是，前端提交的日期字符串和后端LocalDateTime之间的格式转换，稍有差异就可能出现解析异常。

我的统一做法是：数据库层用datetime存绝对时间，Java实体用LocalDateTime接收，前端展示时在后端VO中直接格式化为"yyyy-MM-dd HH:mm:ss"字符串，避免前端重复处理。这个约定在多个模块统一执行后，日期相关的Bug就基本消失了。

7.4 前端打包发布后的路由404问题

本地开发一切正常，但把前端打包部署到Nginx后，刷新非首页路由就会出现404。原因是Vue Router的history模式在服务器端找不到对应的物理文件路径，需要Nginx配置try_files指令把所有路径回退到index.html：

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

如果你不熟悉Nginx或没有独立服务器，也可以把router改成hash模式，地址栏会多一个#，但部署时不需要任何服务器额外配置，对纯静态部署更友好。这两种方案我都验证过，实际项目中根据部署环境二选一即可。

7.5 文件上传大小限制与富文本问题

系统里成果管理模块涉及附件上传，我在这里踩过两个小坑。第一个是SpringBoot默认单次上传文件大小限制为1MB，超过就直接报错。需要在application.yml里调大限制：

spring: servlet: multipart: max-file-size: 20MB max-request-size: 100MB

第二个是前端上传组件和后端接口的字段名必须一致，Element UI的el-upload组件默认上传字段名是file，如果后端MultipartFile参数名不叫file，就需要在组件里配置name属性。这种问题排查起来不复杂，但第一次遇到时确实会浪费不少时间。

写在最后：这套项目后续可以怎么扩展

整个项目跑通之后，剩余的优化空间其实还很大。我自己在后续迭代中考虑的方向有两个：一是把消息中心从简单的站内信升级为WebSocket实时推送，导师确认申请、审核结果同步，不用等刷新；二是引入更细粒度的权限模型，把菜单权限细化到按钮权限级别，目前基于角色的一层权限控制虽然够用，但不灵活。

如果你是在这个项目基础上做二次开发，建议优先补上数据导出功能，培养计划和成果记录按Excel导出是实际使用中频繁被提到的需求。代码层面，可以把公用的分页参数封装成一个通用请求对象，配合MyBatis的PageHelper插件，分页代码能进一步精简。

最后分享一个我在整个开发过程中体会最深的一点：这套系统本身的业务并不难，真正的价值在于它完整串联了数据库设计、后端接口、前端页面和部署交付的全过程。好好把每一步弄明白，比急着堆功能有价值得多。