做校园生活服务平台的毕设，选SpringBoot加Vue这个组合，可以说是最稳的一条路。这个题目在全国范围内已经被做了不知道多少遍，但每年依然能出新意，原因也简单：校园生活服务平台涵盖的业务场景太典型了——二手交易、失物招领、社团活动、跑腿代办、信息发布，随便挑一个都能撑起一篇论文的核心章节，更不要说你把这几个模块整合到一个系统里，对应的就是一套完整的权限管理、数据流转和业务状态机设计。答辩的时候不管是讲技术方案还是讲业务逻辑，都有实实在在的东西可以说，不会出现“做了个网页但不知道做了什么”的尴尬情况。
这个项目适合谁？两类人：一类是计算机相关专业、需要完成毕设又想学到真实企业级开发流程的同学；另一类是打算考研或就业，想通过毕设把简历上“熟悉Java技术栈”变成“独立设计与实现过实际系统”的同学。这篇文章我会把从选题、技术选型、前后端设计，到论文写作和部署答辩的完整链路都拆开讲，每一部分都带上我实际带毕设过程中踩过的坑和总结出的经验，争取让你少走弯路。
1. 选题定位与需求分析：这个系统到底要解决什么问题
1.1 校园生活服务的真实痛点
先说需求分析，这是论文里“绪论”和“需求分析”章节的核心素材。你去看学校里的真实情况，学生的日常信息流通基本靠微信群、QQ群、表白墙和贴吧，这些渠道的缺点非常明显：信息分发快但是沉淀不下来，三天以后想找一个月前的一条二手交易信息，翻聊天记录能翻到崩溃。失物招领更是典型的痛点场景，丢东西和捡到东西的人经常互不知情，信息不对称极其严重。
所以校园生活服务平台要解决的核心问题，归纳起来就是三句话：让闲置信息有处可存，让需求双方有路可寻，让可信交易有据可依。这三句话就是你论文里做功能划分的根本依据。二手市场解决“存”和“寻”，失物招领解决“寻”，跑腿和代办解决“路”的延伸，而统一的用户系统和信用体系解决“据”。
1.2 功能模块怎么拆才合理
很多同学喜欢一上来就规划二十个功能模块，这样看起来系统很庞大，但论文一旦写起来就会发现每个模块都浅尝辄止。我的建议是控制在五到六个核心模块，每个模块都要有明确的业务闭环。
我推荐的模块划分方式是：
用户模块：注册、登录、个人信息维护、头像上传，这是整个系统的基础。
二手交易模块：商品发布、商品列表浏览、商品搜索、发布记录、交易状态流转（在售、已被拍下、已完成、已下架），这是核心中的核心。
失物招领模块：失物发布、拾物发布、领取申请、审核确认。这个模块天然适合做状态机，论文里有很大的发挥空间。
校园活动模块：活动发布、活动报名、报名列表、活动通知，可以延伸出活动收藏和按类型筛选。
校园跑腿模块：订单发布、订单接单、状态流转（待接单、进行中、已完成、已取消）。
个人中心与消息模块：我发布的内容管理、消息通知。
这几个模块组合起来，业务上是一个完整的校园生活闭环，技术上则覆盖了增删改查、文件上传、状态流转、模糊搜索、权限拦截、前后端交互这些毕业设计必须展现的技术点。
1.3 角色与权限怎么设计
角色设计建议做成三种：普通学生用户、管理员、超级管理员（你自己）。不要做得太复杂，不要让普通用户去配置什么权限策略，那是企业级系统的玩法，放到毕设里反而显得冗余难讲清楚。
角色区分用最简单实用的方式：用户表里加一个 role 字段，用数字区分。普通用户的角色值是1，管理员是2。后端用一个自定义的拦截器或者 SpringBoot 的拦截器配置去拦截 /admin/** 路径，只有 role 为2的用户才能访问。超级管理员其实可以在系统里写死一个账号，不需要单独给角色表加字段。前端配合使用Vue Router的路由守卫来实现页面级别的跳转控制，后端再用拦截器做接口级别的保护，这样双层防护，答辩时你能讲出“前后端双重校验”的安全设计思路，这是加分项。
2. 技术选型分析：为什么是SpringBoot加Vue，而不是别的
2.1 后端选型：SpringBoot的匹配度在哪里
SpringBoot 在这个项目里的定位几乎完美。你看它的两大设计理念：约定优于配置、自动装配，刚好对应毕设的两大需求——开发效率高、原理好解释。自动装配机制让一个 Web 项目只需要引入 spring-boot-starter-web 就能跑起来，不用像 SSH 时代那样去配置一堆 XML。论文的“相关技术”章节写 SpringBoot 的自动装配原理，一句“基于条件注解和 starter 机制，在项目启动时自动加载所需的 Bean 配置”就能讲透，同时还能引出你在项目中如何使用 @Configuration 和 @Bean 做的自定义配置。
版本选择上，我给的建议是 SpringBoot 2.7.x，搭配 JDK 8。原因很简单：稳定、资料多、兼容性好。SpringBoot 3.x 基于 Jakarta EE，要求 JDK 17 起步，虽然新，但很多培训机构团队都不愿在毕设场景下推荐它，因为网上能找到的资料和问题解决方案大部分还停留在 2.x 时代。2.7 是 2.x 系列的最后一个稳定版本，从功能上来讲足够你用了。
2.2 前端选型：Vue到底学哪一代
前端就用 Vue3 + Vite + Element Plus，这个组合现在已经是事实上的默认选项。Vue 3 相比于 Vue 2 最大的改进是组合式 API 和 Composition 代码复用机制，使状态逻辑的复用不再依赖 mixin 那种不透明的写法。论文相关技术章节里写 Vue 的时候，建议重点讲三点：数据响应式原理、组件化开发、路由与组件的关系。能够把这三点讲清楚，对一个本科生来说已经是超出预期的水平了。
Vite 的主要优势是启动速度快，npm run dev 秒级启动，改代码热更新体验很好，对开发效率的提升非常明显。构建工具的选择虽然不算核心创新点，但在论文里写“采用 Vite 作为前端构建工具，利用其基于原生 ESM 模块的热更新时间优势，显著提高开发调试效率”，这句话是有分量的。
2.3 存储方案的组合拳：MySQL + Redis + MinIO
数据库用 MySQL 8.0，理由不用多说，关系型数据模型最适合校园类业务系统的结构化数据存储。Redis 用来存什么东西要说清楚，我不会建议你在毕设里因为“用过 Redis”而生硬地加缓存，最自然的用法是：把登录成功后生成的 Token 存到 Redis，设置过期时间，实现服务端可控的用户会话；把二手商品列表的首页热门数据做缓存，减少数据库查询压力。这两种用法逻辑自然，答辩时也能充分解释为什么Redis适合做这一切。
文件存储选 MinIO。这个部分值得单独说。校园二手交易需要商品图片，失物招领也需要上传照片，如果你把图片以二进制或 Base64 直接存到 MySQL，那表体积很快就会膨胀，备份和查询都会变慢。MinIO 作为一个开源的对象存储服务，部署简单，Docker 一条命令就能拉起来，有 Web 控制台可以查看上传的对象。SpringBoot 集成 MinIO 的套路是：引入 minio 的 Java SDK，在配置类中注入 MinioClient 实例，再写一个 FileService 封装上传、删除、获取预签名 URL 的方法。论文相关技术章节可以把 MinIO 放在非关系型存储的类别里写，重点突出“对象存储与关系型数据库组合解决多元化数据存储问题”的思路。
这里还搜到一个比较进阶的点：如果用了金仓数据库或者需要做读写分离的配置，那属于国产化或高并发场景的扩展。毕设里一般不建议碰，因为校园生活平台没有那个量级。你可以在论文的展望部分提一句“未来可考虑引入读写分离架构应对更大规模并发访问”，点到为止即可。
3. 系统整体设计：从逻辑框架到接口规范
3.1 经典的分层架构设计
代码分层的逻辑要提前想清楚，我推荐的形式是：
controller 层负责参数接收、调用 service、返回统一响应
service 层负责业务逻辑处理和事务控制
mapper 层负责数据库 CRUD，用 MyBatis-Plus 简化单表操作
entity 层定义与数据库表对应的实体类
config 层放各种配置类，如跨域配置、拦截器配置、MinIO 配置
common 层放统一返回对象 Result、全局异常处理器、业务异常类
util 层放工具类，比如 JWT 工具、日期格式化工具
分层的好处是职责清晰，每一个类的职责都是单一的，出了问题能快速定位。这对于后面写论文“系统设计”章节的类图、时序图大有帮助。你在画图的时候，照着这个包结构画出来就是一个标准的 SpringBoot 项目架构图，根本不用另外再造一个结构。
3.2 统一响应体的设计
统一响应体是前后端分离项目的容错核心。设计一个 Result 类，包含 code、message、data 三个字段。正常请求返回 code=200；业务异常返回 code=400 或 500，message 给具体的错误信息；未登录或登录过期返回 code=401。前端 axios 拦截器里统一判断返回码，如果 code 是 401，就跳转到登录页并清除本地登录状态。
这套设计会让你的接口开发体验直线提升。每个 Controller 方法不需要自己写 try-catch 去处理异常，服务层抛出 BusinessException，全局异常处理器 @RestControllerAdvice 统一捕获并转成 Result 对象返回。前端不管是数据加载失败还是后端处理器异常，都能正常拿到结构一致的 JSON 响应，前端只需要根据 code 值来做分支展示，不需要一行一行对返回结构进行防御判断。
3.3 数据库设计的几个关键原则
数据库设计直接决定后面写代码的效率，我带你过一遍核心表的建立逻辑。
用户表 user：主键、用户名、密码、昵称、头像路径、手机号、角色字段、创建时间、状态字段。密码存储务必要用加盐哈希，我建议用 BCrypt 算法，Spring Security 框架内置了 BCryptPasswordEncoder，不用额外引包。别直接存明文密码，答辩时被问到安全问题你将无话可说。
商品表 goods：主键、发布者 ID、商品标题、描述、价格、图片路径（多个逗号拼接）、分类、状态字段、发布时间。状态字段的设计值得展开讲——用 int 类型 0 表示在售，1 表示已拍下，2 表示已完成，3 表示已下架。这个字段就是前面提到的业务状态机的载体。你可以在服务层写一个状态变更方法，加 @Transactional 事务注解，保证同一时刻状态只能按顺序迁移。
失物表 lost_found：主键、发布者 ID、类型（0拾到 1丢失）、标题、物品描述、丢失或拾到地点、图片路径、联系方式、状态（0待认领 1已完成）、发布时间。
活动表 activity：主键、发布者 ID、标题、内容、开始时间、结束时间、报名截止时间、所属社团或组织、状态字段。
跑腿订单表 order：主键、发布者 ID、接单者 ID、物品描述、起点、终点、希望完成时间、状态（0待接单 1进行中 2已完成 3已取消）、下单时间。
表与表之间的外键关系怎么处理？我的建议是逻辑外键，不建物理外键约束，而是通过字段名关联。理由有两个：一是逻辑外键在删除数据的时候更方便，不会触发外键约束错误；二是 MyBatis-Plus 操作单表时更顺手。你可以在实体类里通过注解写出表关联的关系，比如商品里的 sellerName 字段直接冗余卖家昵称，查询商品列表时免去联表查询，这种做法在实际项目中非常常见，论文里解释为“以空间换时间，提升查询效率”。
4. 后端核心功能实现细节
4.1 登录鉴权与 Token 机制
登录功能是整个系统最先要打通的部分。流程是这样：前端把用户名和密码传给后端的 /api/user/login 接口，后端用用户名查库取到密码哈希值，用 BCrypt 校验密码是否匹配，匹配则生成 JWT，把 JWT 和用户ID存到 Redis 并设置过期时间，再把包含用户信息和 token 的对象返回给前端。前端本地存储里把 token 保存下来，之后每一次请求，axios 请求拦截器都会在请求头中带上 Authorization: Bearer 这个 token。
后端的拦截器要做的事情是：从请求头里取到 token，通过 JWT 解析出用户信息，去 Redis 里查这个 token 是否存在且未过期，都满足就把用户信息放到 ThreadLocal 或者 request 属性里，放行请求。不满足就返回一个“未登录”的 JSON 响应，前端接到 401 状态码统一跳转登录页。
需要注意的细节：JWT 的密钥不要硬编码写在代码里。放到 application.yml 配置文件中，读取时通过 @Value 注入。过期时间我建议设置成 30 分钟，因为整合了 Redis 之后你可以做“滑动过期”，即每次操作接口时都刷新 Redis 里的过期时间，用户就会一直保持在线，只要他 30 分钟内有过操作。
4.2 文件上传：SpringBoot 整合 MinIO
这个功能是很多毕设都会做但做得不够好的地方。文件上传的完整流程是：前端用 Element Plus 的 el-upload 组件，配置 action 地址指向后端的 /api/file/upload 接口，把文件以 multipart 格式 POST 给后端。后端接口接收 MultipartFile 类型参数，然后调用 MinIO 上传服务，把文件流写入桶内的指定路径。上传成功的返回值里包含一个可在浏览器直接访问的 URL。
MinIO 在 SpringBoot 里的配置方式我展开讲一下。先添加依赖：io.minio:minio:8.5.7。再写配置项：minio.endpoint、minio.access-key、minio.secret-key、minio.bucket-name。配置类的代码如下：
@Configuration public class MinioConfig { @Value("${minio.endpoint}") private String endpoint; @Value("${minio.access-key}") private String accessKey; @Value("${minio.secret-key}") private String secretKey; @Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } }上传方法的核心逻辑是用 InputStream 构建 ObjectWriteArgs，设置好 contentType，然后调用 putObject。返回的 URL 拼接方式要注意：直接用 endpoint 加桶名加对象名，服务端关闭签名的话浏览器可以直接 GET 预览。头像上传、商品图片上传、失物图片上传，这三个业务场景全都复用同一个 FileService，代码量不会增加太多。
这里有一个实际项目里常见的问题：SpringBoot 对上传文件大小默认限制是 1MB，超过会被拦截并抛异常。你必须在配置文件里做两处设置：
spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB这句话不加上，你会发现发个稍微大一点的商品图片就报 500，排查一整天发现是默认大小限制，这是经典坑之一。
4.3 核心业务状态机：商品交易和跑腿单流转
业务状态机是毕设里能展示你设计能力的关键设计。拿二手交易来说，商品表的 status 字段在不同状态下对应的操作权限分为四类：在售状态可被搜索和浏览，可被下单；已拍下状态，其他用户不可再下单，发布者可以确认完成或取消交易；已完成状态，所有操作终止，交易计入双方记录；已下架状态是自己主动下架触发的终态。
后端实现时，建议在 Service 层写一个专门的私有方法 adjustGoodsStatus，传入商品 ID、期望变更前状态和期望变更后状态。方法内部先查当前状态，比对预期前置状态，不一致则抛出业务异常“状态不允许变更”。代码逻辑类似下面的伪代码：
public synchronized Boolean updateStatus(Integer goodsId, Integer fromStatus, Integer toStatus) { Goods goods = goodsMapper.selectById(goodsId); if (!fromStatus.equals(goods.getStatus())) { throw new BusinessException("当前状态不允许执行该操作"); } goods.setStatus(toStatus); return goodsMapper.updateById(goods) > 0; }值得注意的是加 synchronized 关键字，同一时刻只允许一个线程修改同一个商品的状态，防止并发下两个用户同时下单导致状态错误。这个细节虽然简单，但是答辩时讲出来，评委眼睛里会有光。
4.4 定时任务与业务提醒
校园业务里有几个场景适合用定时任务：失物招领信息超过 N 天无人认领自动置灰或标记过期、活动开始前一天给报名用户发送站内信提醒、跑腿单超过 24 小时没人接自动取消。SpringBoot 的做法用 @EnableScheduling 开启定时任务，然后通过 @Scheduled(cron = "0 0 0 * * ?") 去制定固定时间扫描数据库中的待处理状态记录。
定时任务在论文里属于“系统特色功能”的板块，点位不多但非常好讲。你要注意的问题是：定时任务不要写得太重，不要在循环里一遍遍查询和更新。更推荐的做法是写一条条件 SQL 批量更新符合条件的记录，比如把 update_time 超过 30 天的在售商品直接改成已下架状态，一次更新完成。
5. 前端核心开发落地
5.1 工程初始化与目录结构规划
前端开发第一步是装环境。Node 版本推荐 18 或 20，不要用最新的 22 系列，部分旧依赖会有兼容问题。用 npm 安装脚手架时如果速度太慢就换淘宝镜像源，这个网络问题上不用客气。
使用 create-vite 创建 Vue3 工程，然后安装 vue-router 和 pinia。目录规划的参考结构：
src/views 里放页面组件，按模块分文件夹：user、goods、lostfound、activity、order
src/router 里放路由配置文件
src/api 里按模块封装后端接口请求函数
src/utils 里放 request.js 封装的 axios 实例
src/stores 里放 pinia 状态管理模块
这个目录结构在你写论文系统实现章节时可以直接画成一个系统结构图，不需要额外加工。
5.2 请求封装：axios 拦截器的标准写法
前端和后端能联动通畅，核心在于 request.js 的封装质量。直接把 axios 原样在组件里用会出现大量的重复代码。我建议封成统一的模块，代码骨架长这样：
const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = 'Bearer ' + token; } return config; }); request.interceptors.response.use(response => { const res = response.data; if (res.code === 200) { return res.data; } else if (res.code === 401) { localStorage.removeItem('token'); router.push('/login'); return Promise.reject(new Error(res.message)); } else { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } }, error => { ElMessage.error('网络异常，请稍后重试'); return Promise.reject(error); });接口函数统一写在 api 文件夹下，每个接口返回 request 的 Promise 结果，页面里只需要调用带业务含义的函数名。这种方式的好处是页面组件和网络请求彻底解耦，业务代码里看不到跟 axios 配置相关的东西。论文实现章节里前端部分的核心亮点集中在这一个文件你可以重点展开讲。
5.3 路由守卫与动态路由控制
Vue Router 的路由守卫在校园平台里主要有两层作用：未登录状态访问需要登录的页面直接重定向到登录页；已登录但是管理员身份访问普通用户才有的页面时给出无权限提示。
设计中一个比较实用的做法是给路由配置 meta 字段，里面放 requiresAuth 和 role。路由守卫代码逻辑如下：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}'); if (to.meta.requiresAuth && !token) { next('/login'); } else if (to.meta.role && userInfo.role !== to.meta.role) { next('/403'); } else { next(); } });动态路由的使用场景是：不同角色登录后看到的菜单项不同。用 Vue Router 的 addRoute 方法根据后端返回的权限列表动态添加路由，实现前端页面的按权限展示。校园平台的角色数量少，是不不分角色的两个页面区域；如果你想把论文水位拉高一些就可以把动态路由加进去，写一个简单的权限数组判断即可。
5.4 播放 m3u8 视频：一个加分的小功能
再看热搜词里有个 vue 播放 m3u8 免安装，校园平台里的视频功能一般用在活动回顾、失物招领中丢失物品的视频佐证、二手交易中的评测类视频这三种场景。m3u8 是 HLS 协议的播放列表格式，浏览器原生不支持直接播放，常规做法是引入 hls.js 库，前端代码大致是这样：
import Hls from 'hls.js'; export function playM3u8(videoElement, url) { if (Hls.isSupported()) { const hls = new Hls(); hls.loadSource(url); hls.attachMedia(videoElement); } else if (videoElement.canPlayType('application/vnd.apple.mpegurl')) { // Safari 原生支持 videoElement.src = url; } }这个功能的典型应用场景是可以做一个活动直播预约页面，后端管理端上传活动回放视频到 MinIO 并转码为 m3u8 切片，前端在活动详情页内嵌播放器。从小处着眼，这样的功能是加分项，因为它体现了你对流媒体协议的理解，而这是很多普通管理系统根本不会涉及的领域。
5.5 UI 细节：内容折叠展开与前端的交互体验
Vue 里做内容的折叠展开，Element Plus 的 el-collapse 组件直接够用。如果你需要自定义一个“查看更多”的效果，可以用 ref 控制一个布尔变量，配合 transition 组件做平滑展开。
页面交互层面的建议是：列表页不要直接用表格硬铺，二手商品用卡片式和瀑布式布局会更强贴近 C 端产品的体验；详情页要有图片预览，el-image 的 preview-src-list 属性支持点击放大预览；空数据时要展示空状态，不要只有一张空白页。
Vue 样式这块有个常遇到的问题：b 站或社区里有人用 vscode 在 vue 标签中跳转失效的帖子。你在开发时提前在 jsconfig.json 里配置好路径别名 @ 指向 src，就可以在编辑器里通过 Ctrl+点击直接跳到组件的定义和引用的地方，包括 router 和 api 路径的跳转。这个小配置在开发效率上的帮助，比你想象的还要大。
6. 毕业论文撰写：从章节规划到答辩预备
6.1 毕业论文的章节骨架怎么搭
开题阶段的论文大纲很关键，直接决定你后面三个月的写作节奏。推荐采用下面的骨架：
摘要：一句话说清楚系统是什么、用什么技术、解决了什么问题，字数控制在 300 字以内
第一章 绪论：研究背景与意义、国内外研究现状、课题研究内容、论文组织结构
第二章 相关技术介绍：SpringBoot、Vue、MySQL、Redis、MinIO、前后端分离概念
第三章 系统需求分析：可行性分析、功能需求分析、非功能需求分析、用例图
第四章 系统设计：系统总体架构设计、功能模块设计、数据库设计、接口设计
第五章 系统实现：后端核心模块实现、前端核心模块实现、关键代码分析
第六章 系统测试：测试环境、功能测试用例、测试结果分析、兼容性测试
第七章 总结与展望：工作总结、不足与未来方向
每一章的写作技巧是：先讲背景思路，再给出设计表现，最后做一个小结。不要在一个章节里堆一大段代码，代码只展示核心方法的关键片段，每段代码后面都要配上解释这类写法的作用和原因。
6.2 图表绘制：画图的质量决定了论文的观感
评审和答辩老师看论文，一定会大量看图。图的质量需要认真对待。用例图、E-R 图、系统架构图和数据流图，这几类是必备项。
工具方面推荐 ProcessOn 或 Draw.io。绘图的时候有一个原则：图里的每个元素都要在正文中有对应的文字说明，不要出现一张“孤儿图”。数据库设计章节至少包含一张完整的 E-R 图，实体属性要跟表字段保持一致。功能结构图用层级图的形式把模块放进去，体现模块的父子关系；时序图画一个用户发帖或下单的完整流程，画清楚前端、后端、数据库之间的调用关系。毕业设计答辩现场讲师抛出“这个系统的工作流程是什么”的问题，你就可以直接联系时序图来讲，流畅度和可信度都会很高。
6.3 测试章节怎么写才能过审
测试部分是最容易写的也是检查严的。不要只写“测试结果正常”、“系统运行稳定”这样一句话带过。建议列一张具体的功能测试用例表，包含字段比如：测试编号、测试模块、测试步骤、预期结果、实际结果、测试结论。手工准备不少于二十条用例，覆盖登录注册、商品发布、下单流程、失物认领、后台管理这几个核心业务线。
非功能测试部分写一下兼容性：在 Chrome、Edge、手机浏览器上分别验证页面渲染和功能是否正常；用 JMeter 做一个简单的压测，说明系统在几百个并发请求场景下的响应时间和错误率。即便你只跑了一次压测工具，实际数据都是撰写的材料，但前提是你真的在本地做过一次，答辨老师追问时才能答得上来。
6.4 查重与降重的实操经验
论文模板和范文在知网查重中很难完全避免重复率过高的问题。章节结构通用描述和技术名词介绍的段落往往是重灾区。一个有效的降重方式：把“技术介绍”章节里的每个技术点都与你项目中的具体场景做关联。比如同样介绍 SpringBoot，你加入了“本次校园衣旧捐赠平台采用 SpringBoot，是因为它的自动装配机制可以快速整合数据库、缓存、对象存储等多个组件，减少配置代码量的同时保证了模块之间的兼容性”。
论文里中文重复率过高的问题，通常需要你在写相关技术的时候用“自己的话”叙述，多从功能的用途和你如何使用它两个角度重新组织语言，而不是复制一堆概括性的背景介绍。具备项目实践的细节支撑，既降低了重复率，又增强了论文的落地感。
7. 集成与部署、常见问题及避坑总结
7.1 打通前后端联调的环节
前后端分离开发的过程中最怕出现的是跨域问题。本地开发环境下，Vite 服务占 5173 端口，后端占 8080 端口，端口不同导致浏览器默认的政策拦截。解决方案在 Vite 的配置文件里面加代理设置，把 /api 开头的请求转发到 8080：
server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }生产环境部署时，用 Nginx 把前端的静态资源目录和 /api 反向代理地址配在一个 server 下面，这样对外就只有一个端口，跨域的问题也就顺带消失了。
7.2 打包与部署的注意事项
前端打包后生成 dist 目录，里面是静态文件，放到 Nginx 的 html 目录下就能跑。有个学生遇到的问题是：打包后刷新一个非首页的页面就 404 了。原因在于 Vue Router 默认使用 history 模式，路径对应的是前端路由而非真实文件路径，刷新时服务器找不到这个文件。解决办法是在 Nginx 配置里加一项：
location / { try_files $uri $uri/ /index.html; }这句配置让所有未命中的路径请求都回到 index.html，由前端路由接管页面展示。这是部署阶段最经典的一个问题，没在 Nginx 上写过配置的是体会不到这种踩坑切肤之感的。
后端打包用 mvn clean package，注意 application.yml 的配置能不能适配生产环境，特别是数据库地址、Redis 地址和 MinIO 地址。这几个地址如果你在开发环境用的是 localhost，到服务器就复制不行，会连不上数据库。Docker 部署的话，把这些中间件分别做成容器，然后通过 docker-compose 把 SpringBoot 应用和中间件编织到一个网络里，各个服务用服务名互相访问。这一套你已经都会的话，写论文部署章节时就有实操素材，单单讲清楚“Nginx 反向代理 + 双容器互通”这个链路就超过大部分照搬教程的文章质量。
7.3 高频报错排查速查表
端口被占用：启动报 Port already in use。处理：用 netstat -ano | findstr 8080 查占用惊醒 PID，然后在任务管理器结束对应进程；Linux 上用 lsof -i:8080 + kill -9。
启动扫描不到实体类：检查启动类是否在正确的包根目录，或者确认 Mapper 接口上加了 @Mapper 注解。SpringBoot 启动类默认从自己所在的包开始往下扫，如果 Controller 或 Service 放置的位置不在启动类同包或子包下，就永远注册不到 Bean。
前后端联调 401 异常：先看后端返回的具体 JSON，再确认前端是否成功保存了登录返回的 token，以及 axios 拦截器是不是在这个请求上添加了 Authorization 头。
文件上传失败：排查项依次是 MinIO 服务是否启动、桶是否存在、Access/Secret Key 是否正确、上传代码路径是否包含了文件名中文导致 URL 编码问题，最后看 SpringBoot 的文件大小限制是不是拦了你。
定时任务不执行：检查启动类或配置类是否缺少 @EnableScheduling 注解，以及 cron 表达式的秒位是否写错（cron 表达式大多数情况下要求至少六位）。
Vue 页面中引入某个组件后控制台报 Cannot read properties of undefined：多数情况是接口返回的 data 结构和前端定义的不一致，打印一下 response 看里面的字段名到底叫什么。这也验证了统一响应体和字段命名规范的重要性。
8. 给后来人的几句实在话
8.1 代码量和业务完整度比花样更重要
我做毕设辅导这些年，最想告诉你的一个规律是：评委评价一个毕业设计好不好，第一看的不是你用了多少新技术，而是你的系统能不能完整跑通一个业务闭环。一个只能发帖但不能编辑和删除的二手交易系统，和一个不好看但能完成发布、下单、确认收货全流程的系统，后者拿高分的概率远远高于前者。所以开发的优先级先定三个：先保证主流程通，再补充边界和异常处理，最后再考虑页面美观和动画效果。
8.2 学会把问题拆成“可控的小步骤”
对着一个没有摸过的新技术栈，你怕的是不知道从哪儿下手。解决这个问题的方法论是：把大任务拆解成小步骤。比如你要做商品的图片上传，就拆成四步：先学会在 MinIO 控制台手动上传并看到文件，再写一个 SpringBoot 接口完成上传并返回 URL，然后用 Postman 调试这个接口确保它能通，最后才去前端写组件调接口。每一步都有明显的完成标志，你就不会被庞大的知识面吓倒。写论文也一样，把“写第二章”拆成“先写 SpringBoot 那一小节”，一旦写了 500 字，今天的写作任务就算完成。
8.3 保留好你的开发日志，那是论文素材的金矿
我建议你在编码阶段养成一个简单的习惯：每完成一个功能或踩了一次大坑，就在开发日志里记一两句话，比如“前端跨域通过 Vite 代理解决”“商品状态流转加了 synchronized 防止超卖”。这些碎片化记录最后会变成你论文里“系统实现”章节的具体素材，也是你在答辩前准备“你在开发过程中遇到的最难问题是什么”时的最优答案。我见过太多学生到了写论文阶段对着空 Word 文档发愁，而平时微信里记录的信息早就在项目调试过程中散落各处。开发日志是这个成本几乎为零、回报最高的习惯。
用我个人的体验收个尾：做毕业设计的这几个月，是大学里唯一一次没有人催着你推进度，却最像真实项目经历的体验。你为这个校园生活平台写下的每一行代码、画的每一张架构图、跑过的每一条测试用例，将来都会成为你简历上可以拿出来讲的故事。把项目当成一件作品去打磨，论文自然会有料。
