SpringBoot+Vue校园网上店铺毕设全流程：从数据库设计到答辩演示

说实话，看到“SpringBoot+Vue 校园网上店铺”这个毕设题目，我第一反应是：又是个经典题。做Java Web方向的东西做久了，校园电商这种前后端分离的全栈项目，差不多是出现频率最高的一类毕设选题。但接触得越多，我越觉得这个题被严重低估了——很多同学以为就是一套增删改查，真上手才发现，从SQL脚本到接口文档，从前端Token到订单状态机，每一步都有能让你卡住两天的细节。

这篇文章我就以“校园网上店铺设计与实现平台”为一个完整例子，把SpringBoot+Vue这种Java Web毕设从数据库设计、后端实现、前端联调，到最终交付验收的全流程拆开讲清楚。适合两类人：一是准备做这个题目、但还不太有把握的同学，二是代码已经写完、但总觉得哪里不踏实、想找一张最终检查清单的同学。目标只有一个：让系统在答辩现场从头到尾跑通，导师问什么你都能答得上来。

1. 先别急着写代码：这个题目的验收逻辑藏在哪里

1.1 一个“看似简单”的项目，交付物其实有四件

很多同学拿到题目就直接打开IDEA开始写代码，写到一半才发现，这个项目要交付的东西远比想象中多。一份完整的校园网上店铺毕设，交付物至少是四件套：后端源码、前端源码、SQL脚本、接口文档。部分学校还要求一份设计文档或者结题报告。

后两端往往被忽视，但它们恰恰是导师和评阅老师最先打开的东西。原因很实际——源码不可能逐行看完，SQL脚本和接口文档却能快速反映你对整个系统的理解深度。接口文档要写清楚每个接口的URL、请求方式、参数、返回示例、错误码，SQL脚本要做到从新建数据库开始一键执行不报错。你如果把这两件事做扎实了，答辩就有了最基本的底气。

1.2 先想清楚三类角色和三段核心流程

校园网上店铺，业务视角上看就是一个小型B2C电商平台。角色划分比普通电商清晰得多：学生是买家，店主是卖家，管理员管平台。这三类用户对应着三段核心业务循环。

买家流程：注册登录 -> 浏览商品 -> 加入购物车 -> 提交订单 -> 模拟支付 -> 确认收货 -> 评价商品。

店家流程：申请开店 -> 上架商品 -> 查看订单 -> 发货 -> 统计自己的商品销量。

管理员流程：审核店铺 -> 管理商品分类 -> 管理公告 -> 禁用违规用户 -> 查看整体订单数据。

一个毕设只要把这三段流程完整串起来，业务闭环就算成立。相反，功能点堆得再多、页面做得再花哨，只要用户从下单到收货这个闭环走不通，答辩就会很被动。

1.3 毕设答辩的评价标准其实很实际

我带过的学生里，有一种很典型的心态：总觉得功能越花哨越安全，于是研究了大把中间件、各种高级算法，最后基础的主链路反而没走通。

答辩评分的核心就是三件事：功能能不能闭环、代码是不是自己写得出、文档是不是完整。导师不一定要求你用到了Redis、消息队列、分布式锁，但他一定在意你打开演示页面后能不能按顺序跑完完整业务路径。我后面所有篇幅，都是围绕这三条评价标准来展开的。

2. 技术选型不乱来：为什么SpringBoot+Vue是当下最稳的组合

2.1 三种常见方案，为什么前后端分离最稳

校园网上店铺这种题，候选人通常有三条路。

第一条路是SSH或SSM加JSP。优点是课堂上都学过，资料多，但前后端耦合在一套工程里，页面效果平平，答辩时也很难展示出“系统设计”上的亮点，更重要的是和当前实际开发模式脱节太远。

第二条路是SpringBoot加Thymeleaf模板渲染。后端一个工程全搞定，省去了前后端联调的麻烦，适合对前端完全不熟的同学。但缺点是交互反馈弱，购物车、订单这类需要频繁更新局部页面的功能，用模板渲染写起来反而更别扭。

第三条路就是SpringBoot加Vue前后端分离。后端只出接口，前端负责页面渲染和交互，职责划分清楚，也是目前真实团队里最常见的协作方式。答辩时你可以讲接口设计、跨域处理、Token鉴权、前后端分离部署，这些都是有含金量的话题。

结论很明确：只要你不是对JavaScript完全过敏，第三路是最值得走的。如果确实前端基础几乎为零，第二路也能毕业，但上限会低不少。

2.2 版本匹配是第一个坑：JDK、SpringBoot、Vue怎么配对

很多同学踩的第一个坑，不是代码逻辑，是版本之间相互不兼容。我把一套在校园网项目里反复验证过、出问题概率最低的版本组合列在下面。

特别注意一个坑：SpringBoot 3.x必须以JDK17为基础，如果你本机还是JDK8，强行上3.x会在启动阶段报各种版本错误。毕设项目长期维护和展示的场景里，新版本带来的收益远小于它带来的不确定性，我历来建议用“求稳”的组合。

2.3 工程结构怎么分，答辩时才讲得清楚

后端建议直接单模块，不要搞多模块依赖，否则打包和启动环节多出一堆麻烦。按业务分包就好：

• controller：接收请求、参数校验、返回结果
• service：业务逻辑，事务控制
• mapper：继承BaseMapper，SQL层
• entity：数据库表对应的实体类
• common：统一返回结果、异常处理、常量定义
• config：拦截器、跨域、静态资源映射等配置类
• utils：JWT工具、密码加密工具等

每个功能模块一个Controller，比如商品、订单、购物车、店铺、管理后台分开写，方法命名做到看一眼就知道干什么。答辩时导师问你某个功能入口在哪儿，你三秒钟就能定位到对应代码。

前端按views的语义划分页面，和后端接口一一对应，会大大降低讲解成本。

3. SQL脚本设计：从表结构到“戏剧化”的种子数据

3.1 核心表别贪多，先把这几张设计明白

SQL脚本是整个项目的骨架，表设计直接决定了后端写的顺不顺手。校园网上店铺的核心表，十张以内足够覆盖全部功能。

• user：用户表，含学生、店主、管理员三种角色
• shop：店铺表，与店主用户一对一
• category：商品分类表
• product：商品表，归属某个店铺和分类
• cart：购物车表
• order：订单主表
• order_item：订单商品明细表
• address：收货地址表
• favorite：商品收藏表
• notice：平台公告表

字段设计上有几个通用细节值得注意。价格一律用decimal(10,2)，不要用float，否则浮点数累计会出精度问题。订单号order_no用varchar(32)存唯一编号，由后端生成，不要依赖数据库自增主键暴露订单量。所有表都加一个deleted字段做逻辑删除，MyBatis-Plus原生支持，省去物理删除带来的外键顾虑。create_time用datetime，update_time用datetime，后端统一在插入和更新时填值。

索引不能忽略。product表给category_id和shop_id各建一个普通索引，order表给user_id和order_no建索引，order_item表给order_id建索引。数据量小的时候索引感知不明显，但答辩遇到“数据库设计”提问时，主动说出索引设计是有加分的。

3.2 订单状态字段的设计，建议直接用一个status

订单是整个项目中状态最多的表，设计时建议直接用tinyint类型的status字段，配合后端枚举类管理，不要用字符串去存“待付款”“已发货”这类中文描述。占空间是一方面，更重要的是字符串比较逻辑散落在代码各处，改动状态时非常容易出遗漏。

后端定义一个订单状态枚举类，把含义和允许的流转方向写清楚。这样下单、支付、发货、确认收货每一阶段更新状态后，下一个状态是什么一目了然，答辩追问状态流转时也讲得清爽。

3.3 种子数据要当成“演示剧本”来准备

SQL脚本里除了建表语句，还要有能直接跑起来的种子数据。这是很多同学容易忽略但影响极大的环节。种子数据的质量直接决定你演示是否顺畅。

至少准备三个账号：管理员、学生、店主。密码字段必须预置BCrypt密文，不要明文存。所谓“登录不进去”的翻车现场，八成都是因为密码字段没做加密，后端用BCrypt校验时就对不上。

商品数据要覆盖分类：数码、文具、零食、图书各准备几条，每个店主账号下挂5到10个商品，价格有梯度，封面图用统一相对路径比如/img/goods/1.jpg，不要写本机的绝对路径。

订单数据建议覆盖两到三个状态：一条待付款，一条待发货，一条已完成。这样演示时，你登录学生账号能看到“待付款的订单点击支付”，店长账号能看到“待发货的订单点击发货”，每一步都有按钮可点，节奏非常连贯。

这里有一个我反复强调的原则：SQL脚本不是写代码的副产品，而是演示的剧本。表结构是权力，种子数据是现场发挥的基础。两者一起交付，才是完整的SQL脚本。

4. 后端核心模块的实现：从登录到下单，这几处别走弯路

4.1 登录鉴权：JWT加拦截器就够用，别堆功能

校园网上店铺这种量级的项目，登录鉴权用Spring Security全家桶其实是杀鸡用牛刀，配置繁琐不说，很多同学用不好反而把自己绕进去。我建议用JWT配合HandlerInterceptor拦截器，轻量、可控、讲解起来也清晰。

简单说就是：用户登录成功后，后端用一份密钥签发一个带有效期的Token，前端存到localStorage里，后续每次请求都在Header里带上Authorization: Bearer <token>。拦截器拦截需要认证的接口，解析Token，解析失败就返回401。

Token工具类建议用jjwt库，核心逻辑只有三件事：生成Token、解析Token、判断有效期。密码校验用BCryptPasswordEncoder，注册时加密存储，登录时比对密文。注册接口、登录接口、商品浏览接口这些不需要登录就能访问的路径，放进拦截器的白名单里。

代码上有个容易翻车的地方：拦截器注册后，静态资源路径，比如上传图片的/img/**，也记得一并放行，否则商品图片加载不出来。

4.2 商品模块：多条件分页查询怎么组织

商品列表页的核心是筛选和分页。前端传关键词、分类、店铺、价格区间、排序方式，后端返回当前页数据和总数。用MyBatis-Plus的LambdaQueryWrapper动态拼接条件最省事。

关键位置是动态条件的判断。传入的条件一旦用了StringUtils.isNotBlank或ObjectUtils.isNotEmpty包裹，就不需要考虑“前端没传参数”这种情况，大大减少空指针问题。

排序也要注意安全，排序字段名最好由白名单机制控制，不要直接把前端传来的字段名拼进SQL，否则比较容易被注入。这个细节在答辩提问环节偶尔会被问到，提前做了就能答得理直气壮。

4.3 订单模块：下单事务和库存防超卖

订单模块是后端业务中最有含金量的部分。创建订单一定要加事务注解，保证订单主表、订单明细、库存扣减、购物车清除任何一个环节失败都整体回滚。

库存扣减建议直接用一条乐观锁风格的SQL，而不是先查库存再判断大于等于购买数量。

sql复制UPDATE product
SET stock = stock - #{quantity}
WHERE id = #{id} AND stock >= #{quantity}

这条SQL的好处是：它在同一句里完成了扣减动作和库存校验。如果受影响行数是0，说明库存不足，直接抛业务异常。两个用户同时买同一商品时，数据库行锁会保证只有一个请求能成功扣减，这就是最简单可讲的防超卖方案。答辩被问到“并发情况下会超卖吗”，用这个思路解释完全够用。

支付功能不要接真实的支付宝或微信支付，毕设环境不具备条件也没有必要。做一个模拟支付接口，下单后点击“模拟支付”，校验订单归属和状态为待付款，然后更新状态即可。把业务逻辑讲清楚才是核心，支付网关的申请和审核不是这个题目的重点。

4.4 文件上传与接口文档的配套经验

商品图片上传是必做功能。后端接收MultipartFile，保存到一个可配置的本地目录，再把访问路径返回给前端。保存路径不要写死成D:\之类，要用配置文件维护，否则换机器跑就崩。

上传目录和静态资源访问要配套处理，在配置类里把本地目录映射成HTTP可访问的路径，这样前端拿到相对路径就能直接拼URL请求到图片文件。

接口文档方面，我用过两种模式：一种是集成knife4j，让Swagger注解自动生成在线文档，好处是接口改了文档自动同步；另一种是手动整理一份接口文档，配合Postman导出的接口集合，适合学校不要求在线文档的场景。无论哪种，接口文档至少要包含：接口名称、请求URL、请求方式、请求参数示例、返回数据示例、错误码说明。这份文档既是答辩材料，也是你自测接口的依据。

5. 前端Vue与后端对接的细节：大多数同学都卡在跨域和Token

5.1 前端工程怎么搭，代理配置是第一步

前端推荐直接用基于Vue的脚手架，Vue2对应Element UI，Vue3对应Element Plus。页面结构按模块分目录，和后端接口一一对应。

前后端联调时，跨域是第一个绊脚石。很多人习惯在axios里直接写http://localhost:8080这种全路径，这样请求一定会触发CORS跨域策略，后端还得配一堆跨域代码去解。

更好的做法是：axios的baseURL只写/api，在开发环境用webpack的devServer代理，把请求转发到后端端口。这样对浏览器来说请求的是同一个域，压根不触发跨域。

javascript复制// vue.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      },
      '/img': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

图片路径也同理，通过/img代理到后端。整套前后端联调跑下来，你不写一行后端跨域代码也能顺畅开发，极大减少沟通成本。

5.2 登录态怎么管理：axios拦截器加路由守卫

登录后的Token管理，前端要做两件事：请求时带上Token，响应时处理失效。

用一个封装的request.js统一处理。请求拦截器里从localStorage拿Token，有就放到Authorization头；响应拦截器里判断业务状态码，如果是401就跳转到登录页，并记录一下当前路由，登录成功后跳回来。

路由守卫控制页面权限。需要登录才能访问的页面在路由meta里标记requiresAuth，需要在beforeEach钩子里面检查Token存在性。管理员页面额外加一个角色判断，比如当前用户角色不是管理员，就重定向到首页，避免直接通过URL访问后台页面。

5.3 图片回显、日期格式化、刷新404：三个高频小坑

上传成功后，后端返回的相对路径需要前端拼上域名前缀。开发环境走代理用相对路径就好，部署到生产环境后要在Nginx里同时做前端路由和静态资源目录的转发。

日期显示也是高频踩坑点。SpringBoot默认对LocalDateTime的JSON序列化格式可能是一串很长的数字，不是可读日期。建议在全局配置里统一定义日期格式，推荐yyyy-MM-dd HH:mm:ss，一次配置全局生效，避免每个实体类单独加注解。

前端路由用history模式时，刷新页面会出现404。毕设项目最省心的方案是直接用hash模式，或者后端配合做路由兜底。这种问题的排查成本往往高于修复成本，提前选对模式能少熬一次夜。

6. 交付之前的最终检查：源码、SQL脚本、接口文档与答辩提问

6.1 一份能直接跑起来的README比什么都重要

代码写完后，最后一天花时间最多的不是改代码，是整理文档。我强烈建议你写一份README，按以下顺序组织：环境版本、启动步骤、演示账号、接口文档入口。

启动步骤写成从零开始也能照做的版本，大致是：

1. 新建MySQL数据库，执行项目里的sql脚本
2. 修改application.yml中的数据库账号密码等配置
3. 启动后端SpringBoot工程，访问Swagger接口文档页确认接口正常
4. 前端工程执行依赖安装，启动开发服务
5. 用README中的三套演示账号分别登录，走一遍核心流程

这份README不仅是给评阅老师看的，也是给你自己留的“逃生手册”。答辩前一个星期，建议把整个流程完整跑两遍，每一步都记录下遇到的问题。

6.2 答辩演示路线：不要即兴，按“脚本”走一遍

答辩现场最容易翻车的环节就是即兴演示。我的建议是提前设计一条固定演示路径，全程五分钟，按顺序点：

1. 管理员登录，查看用户列表、店铺审批列表
2. 店主登录，上架一个新商品，设置价格和库存
3. 退出，用学生账号登录，搜索刚才上架的商品
4. 加入购物车，提交订单，执行模拟支付
5. 切回店主账号，看到新订单，点击发货
6. 切回学生账号，确认收货
7. 打开接口文档页，说明两三个核心接口的请求和响应结构

按这条路线演示，每一段都连接上一个业务闭环，导师跟着顺序看下来，对整个项目的理解会比看一堆零散页面清晰得多。

6.3 容易被导师追问的10个问题，提前准备好答题方向

答辩复习阶段，可以把下面这些问题和回答方向打印出来过一遍。不用死记硬背原文，理解核心逻辑就够。

这些问题的共性在于，它们考察的不是你背了多少概念，而是你是否真的理解了自己写的代码。只要不是照抄开源项目改个皮，用自己的话讲清楚思路并不难。

最后分享一点个人经验：交项目之前，把SQL脚本从新建数据库开始完整执行一遍，后端和前端各自从零启动一遍。这个动作做起来只需要十几分钟，却能把“登录不进去”“图片显示不了”“端口冲突”这类低级问题全部暴露掉。一次完整的从零启动验证，比查一百遍代码清单都管用。