SpringBoot+Vue小区购物系统毕设全流程解析

前阵子有个准备做毕设的同学来找我说自己拿到的题目是“SpringBootVue小区购物系统平台”网上下载的参考代码要么缺SQL脚本要么接口文档写得稀碎连登录都没跑通。这个情况太常见了。今天我就拿这类项目当例子把前后端分离的Java Web毕设从设计、建表、写接口、跑前端到部署验收的完整链路拆开讲清楚把源码、SQL脚本、接口文档里该有哪些东西、为什么要有这些东西都说透。这类项目放到毕设里算是非常标准的“管理系统商城”综合体业务量不大不小技术栈又是目前中小公司用得最多的一套面试时也拿得出手。如果你正准备做类似的课题或者刚拿到代码但不知道怎么梳理这篇文章可以当成你的排查手册和答辩提纲用。1. 项目整体设计与技术选型1.1 为什么是 SpringBoot Vue而不是传统的 JSP 项目很多同学会问学校教的是 SSM JSP为什么毕设非要换成前后端分离我的看法是在没有特殊要求的前提下SpringBoot Vue 的组合几乎是对应届毕业生最友好的选择。后端用 SpringBoot省掉了大量 XML 配置内嵌 Tomcat一个 java -jar 就能跑起来。相比以前要手动配置 SpringMVC、MyBatis、数据源那一堆 BeanSpringBoot 的自动配置让新手把精力放在写业务逻辑上而不是和配置文件搏斗。前端用 Vue Element UI页面组件化之后管理后台的布局、表格、表单、弹窗基本都是现成组件拼出来的开发效率比 JSP 里用 jQuery 操作 DOM 高了一个量级。数据交互走 Axios 调 RESTful 接口前后端各干各的调试也方便。从这个项目的实际结构来看挂上 Swagger 或一份 Markdown 接口文档双端并行开发整个工作量非常清晰。答辩的时候“前后端分离”“RESTful 接口”“统一返回结构”这些点也可以讲得很具体比单纯说“我用了 SpringBoot”要有说服力得多。1.2 业务角色与功能模块划分小区购物系统平台核心人物有三类居民用户、平台管理员、配送员。有同学会把配送员放进来做成第三权限也有简化版只做用户和管理员两个端看题目要求。从完整性和答辩展示效果考虑有三个角色会更好展开。居民用户端的功能围绕“浏览商品—加购物车—下单—支付—查看订单”来做同时要有收货地址管理、公告查看和个人信息维护。管理员端则负责商品管理、分类管理、库存管理、订单审核与发货、用户管理、配送管理、公告发布。配送员端相对简单查看配送任务、更新配送状态、确认送达。如果把“小区购物”的业务场景再往深处推一点还可以加一个“配送单”的概念用户下单后生成一个配送单由配送员接单并配送取货时校验取货码。这一套逻辑把“在线购物”从单纯的商品交易变成了带履约特征的同城零售系统业务上更有完整性。1.3 技术栈选型清单分层技术选型选型理由后端框架SpringBoot 2.x自动配置、内嵌容器、生态成熟ORMMyBatis-Plus单表 CRUD 不用写 SQL分页插件好用数据库MySQL 5.7免费、稳定、毕设和中小企业都常见权限认证JWT BCrypt前后端分离场景下无 Session 依赖前端框架Vue 2 / Vue 3组件化开发上手快社区资料多UI 组件Element UI / Element Plus后台管理界面开发效率高接口文档Swagger 或 Markdown便于前后端联调和答辩演示项目管理Maven Node.js前后端依赖管理统一方便这套组合选下来基本覆盖了 Java Web 方向的主流技能点而且能保证一个具备基础的同学在一个月内把核心功能做完。如果你拿到的源码里用的恰好是这些那结构是健康的如果用了很冷门的框架就要考虑是否值得替换。2. 数据库设计与核心表结构解析2.1 表设计清单与字段设计思路数据库是整个项目的底座SQL 脚本质量直接决定了代码能不能跑起来、答辩能不能圆回来。一套合理的小区购物系统至少要包含下面这些表用户表、角色表、用户角色关联表、商品分类表、商品表、购物车表、订单表、订单明细表、收货地址表、配送单表、公告表、库存流水表。用户表最基础字段就是 id、username、password、phone、avatar、status、create_time、update_time。密码字段注意长度不要设计成 32BCrypt 加密后的字符串有 60 个字符用 varchar(64) 更稳妥。很多同学在这里踩坑数据库只给了 45 字符加密串一存就被截断导致每次登录都校验失败。商品表的字段要有category_id、name、image、description、price、stock、sales、status、is_deleted。这里特别注意 price 用 DECIMAL(10,2)不要用 DOUBLE否则累计金额会出现 0.10.20.30000000000000004 这种经典的浮点误差。is_deleted 是逻辑删除标志这样商品虽然下架但历史订单里还能查到名称和图片快照。订单表是整个业务的核心字段建议这样设计order_no、user_id、receiver_name、receiver_phone、receive_address、total_amount、status、remark、pay_time、delivery_time、finish_time、create_time。order_no 用唯一订单号不要直接用自增 id方便后续做对账和客服查询生成规则可以用时间戳 用户 ID 随机数。2.2 订单状态机与库存扣减方案订单状态是答辩时被提问频率最高的点之一。合理的状态流转不能全靠 if else 随意改应该有清晰的状态机。建议用如下状态待支付0 → 已支付/待配送1 → 配送中2 → 已完成3 待支付0 → 已取消4 配送中2 → 已取消5异常场景比如长时间无人配送状态流转的触发动作要对应接口。支付成功后由 0 变 1管理员发货或配送员接单后由 1 变 2确认送达后由 2 变 3。每个状态变更记录下时间字段这就是完整性。库存扣减是另一个重点。最容易被老师抓到的 bug 是“超卖”两个用户同时买最后一件商品结果都下单成功了。解决方式不复杂扣库存的 SQL 用乐观锁思路UPDATE product SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{productId} AND stock #{quantity}update 返回影响行数为 0就说明库存不足直接抛出业务异常订单创建失败。这套方案在小并发场景下完全够用比引入 Redis 分布式锁更易解释也比数据库悲观锁性能更好。强烈建议再增加一张库存流水表记录每次扣减的订单号、商品 ID、变更数量、操作类型。这张表平时不被注意但在排查脏数据和恢复库存时非常有用属于工程化思维的直接体现。3. 后端核心实现与接口联调要点3.1 JWT 登录与权限控制很多老项目用的是 Session但前后端分离之后Session 处理跨域和移动端适配都比较麻烦。用 JWT 的思路是用户登录成功后后端把用户 ID、角色、过期时间打包生成一个 token 返回给前端前端存到 localStorage 里之后每次请求在请求头 Authorization 里带上这个 token。后端通过拦截器解析 token 来识别用户身份。JWT 的好处是无状态、后端不需要存 Session天然适合分布式部署。但要注意几个坑第一token 不能存放敏感数据只放 id 和 username 这类非敏感信息第二token 要有过期时间一般设置 2 小时到 24 小时前端也建议在 axios 响应拦截器里根据 code 为 401 自动跳回登录页第三密码一定要用 BCrypt 加密千万不能明文存储。权限控制这部分推荐用一个简单的拦截器加上角色判断。比如管理员接口在 token 解析后判断 role 是否为 admin不是就直接返回 403。对于中小项目写死的拦截规则比引入 Spring Security 全家桶更容易掌控毕竟毕设答辩时老师问“这个权限怎么实现的”你需要能把自己的代码讲清楚。3.2 下单流程与事务处理下单是这个项目里最复杂的接口也是事务处理最好的展示场景。一个完整下单操作包含这些步骤校验商品存在且上架 → 校验库存 → 预扣库存 → 生成主订单 → 批量生成订单明细 → 清空购物车中对应商品 → 返回订单号和支付信息。这里必须加 Transactional保证这些操作要么全部成功要么全部回滚。否则就会出现“订单创建成功但库存没有扣减”或者“库存扣了但订单没有生成”的脏数据。需要提醒的是Transactional 默认只在抛出 RuntimeException 时回滚所以业务异常最好统一继承 RuntimeException或者明确配置 rollbackFor。另外一个细节是下单接口要支持传入商品列表和数量由后端重新计算价格。有些同学图省事让前端把计算好的总金额传进来这是非常严重的逻辑漏洞用户把 totalAmount 改成 0.01 就能白嫖商品。正确做法是后端遍历查询商品价格、累加计算前端传过来的金额只做展示不作为最终依据。3.3 接口文档与统一返回格式接口文档是很多人忽视但实际上非常重要的交付物。在答辩现场老师拿到项目后第一眼看的往往不是代码而是 README 和接口说明。如果你的接口文档写得清晰老师第一印象就会很好。建议所有接口采用 RESTful 风格并且统一返回格式。定义一个 Result 类字段包含 code、message、data。code 统一约定200 成功、400 参数错误、401 未登录或 token 过期、403 无权限、500 系统异常。前端 axios 统一处理这些返回码后双端联调会顺畅很多。接口文档建议放在项目根目录的 docs 文件夹里使用 Swagger 或者直接维护一份 Markdown。单独列出一份接口清单比较好登录注册、商品分页查询、商品详情、加入购物车、购物车列表、下单、支付、订单列表、订单详情、取消订单、收货地址 CRUD、管理员商品 CRUD、订单发货、配送单查询等。每个接口标明请求方式、路径、请求参数、返回示例。这一步是肉眼可见的加分项。4. 前端页面结构与购物流程落地4.1 前端目录与路由设计Vue 前端目录建议按功能拆成 views、components、router、store、api、utils。views 放页面级组件components 放复用组件api 里按模块封装请求函数utils 放 axios 实例、token 工具、格式化工具。路由设计要注意权限控制。简单做法是在路由配置里给每个路由加 meta 字段标记该页面允许哪些角色访问。在路由前置守卫里做判断router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { return next(/login) } const role localStorage.getItem(role) if (to.meta.roles !to.meta.roles.includes(role)) { return next(/403) } next() })这段代码解决了两个问题未登录用户不能访问任何页面普通用户不能直接通过 URL 输入跳转到管理端页面。前者是登录态校验后者是越权防护都是老师比较看重的点。4.2 购物车与结算模块实现购物车模块推荐用 Vuex 或 Pinia 做全局状态管理。购物车数据可以保存在后端数据库也可以存在本地从毕设角度建议用后端存储购物车表字段包含 user_id、product_id、quantity、checked增删改查通过接口完成这样换设备购物车不丢也更能体现后端设计能力。结算页需要展示用户选择的收货地址、商品清单、下单备注和配送时段。这个系统可以额外做一个“配送时段”的功能——用户下单时选择上午/下午/晚上时间段管理员端在后台按时间段汇总订单安排配送计划。这一处扩展能很好地体现你对业务场景的理解深度。下单成功后前端跳转到订单详情页。如果有模拟支付可以做一个倒计时比如 15 分钟内未支付自动取消订单。后端可以通过定时任务扫描超时订单也可以在下单时返回一个 expiresTime由前端倒计时到时间后调用取消接口。前者更可靠后者实现简单推荐至少做成“前端倒计时 后端取消接口”足以在答辩中讲清楚业务流程闭环。5. 全套源码的初始化和部署流程5.1 环境要求与 SQL 脚本导入拿到源码之后第一步是核对环境版本。这个项目建议的环境JDK 1.8、Maven 3.6、MySQL 5.7、Node.js 14、npm 6。数据库导入 SQL 脚本时要注意几个坑字符集建议用 utf8mb4别用 utf8否则生僻字和 Emoji 会报错导入前先创建数据库再选择该数据库执行脚本检查脚本里是否有外键约束如果没有说明设计时有意保留灵活性是合理的。初始化数据里要包含一个管理员账号例如 admin/admin123密码为 BCrypt 加密后的值、若干测试用户、商品分类与商品数据、测试公告。这直接影响到项目能不能开箱即用。如果导入后登录不上优先排查密码加密串是否匹配可以用 Java 里的 BCrypt 工具类现场验证。5.2 后端启动与前端启动流程后端启动流程比较固定在 application.yml 里配置数据源 URL、用户名、密码以及 MyBatis 的 mapper 路径。启动类直接右键运行或者用命令mvn spring-boot:run启动成功后控制台会显示监听端口默认 8080。如果端口被占用在 application.yml 里改 server.port 即可同时注意前端代理也要同步修改。前端启动稍微麻烦一点。在 vue 目录下执行npm install npm run servenpm install 耗时较长而且容易因为 node 版本不同出现依赖安装失败。如果报错建议删除 node_modules 和 package-lock.json 后重装如果某个包下载失败可以切换 npm 镜像源。前端默认端口一般是 8080和后端冲突需要改 vue.config.js 里的 devServer.port或者配置代理把 /api 开头的请求转发到后端地址。5.3 功能验收清单项目能不能算完整交付可以对照这份验收清单过一遍模块验收项结果登录注册注册后能登录密码加密入库商品浏览首页能按分类展示商品支持分页购物车添加、修改数量、删除、勾选结算下单库存不足提示重复提交不生成多订单支付模拟支付后订单状态变更为待配送订单管理用户查看订单列表管理员可发货配送单配送员接单后状态流转取货码有效公告后台发布后前台可见权限普通用户不能访问管理员页面这一套走下来基本能证明项目是一个完整可运行的系统而不是只写了一部分接口的“半成品”。6. 常见问题与排查技巧实录6.1 环境类问题速查运行阶段遇到最多的不是业务 bug而是环境问题。为了让你少走弯路我直接把常见情况整理成一个速查表问题现象大概率原因处理方法后端启动报数据库连接失败数据源配置错误或 MySQL 未启动核对 URL、用户名、密码确认 MySQL 服务开启SQL 导入中文乱码字符集不是 utf8mb4建库时指定 utf8mb4重新导入前端 npm install 报错Node 版本过高或过低用 LTS 版本删 node_modules 重装前端请求接口 404后端端口和代理不一致核对 vue.config.js 代理 target跨域报错前端直接访问后端端口走代理或后端配置 CorsFilter登录接口报 token 解析失败密钥不一致或 token 过期检查前后端密钥重新登录查询列表时间为空MySQL 时区设置问题数据源 URL 加 serverTimezoneAsia/Shanghai图片不显示图片路径写死改用相对路径或对象存储路径跨域是最容易卡住新手的地方。前后端分离后如果前端在 8080后端在 9090直接用 axios 请求后端就会触发跨域。推荐方案是前端在 vue.config.js 里配置 devServer 的 proxy把 /api 代理到后端地址这样浏览器以为请求是同源的问题就消失了。这种方案也符合生产环境里用 Nginx 反代的做法答辩时可以顺带说一句。6.2 业务与代码类问题排查思路如果说环境问题靠经验业务代码问题就必须靠排查思路了。下单后库存没扣减先看控制台有没有 SQL 日志确认请求是否真的走到了更新库存的方法如果更新语句执行了但影响行数为 0说明库存条件不满足再查商品是否下架或者库存字段是否被并发更新。订单状态一直是待支付优先查支付回调接口有没有被调用再看事务是否回滚。接口返回 500 时不要只盯着前端报错一步到位看后端控制台异常堆栈。最常见的几个运行时异常NullPointerException 通常是对 null 对象调用方法比如用户没有收货地址就直接下单SQLSyntaxErrorException 通常是字段名和实体类属性名不一致MyBatis-Plus 的 updateById 更新不了数据时先确认实体类是否有 TableId 注解以及 id 值是否为空。我给出一个最实用的排查顺序看网络请求 → 看后端日志 → 看数据库数据 → 定位代码。不要直接猜代码逻辑。后端启动时建议把 MyBatis 的 SQL 日志打开配置 logging.level 为 debug这样每个请求执行的 SQL 都会打印出来很多 bug 一眼就能看出来。还有一个容易被忽略的坑如果前端修改了代码但页面没变化多半是浏览器缓存强制刷新即可如果前端报“模块找不到”通常是 components 或 api 文件路径配错了。检查 import 的路径是否大小写正确在 Windows 开发机上大小写不敏感但部署到 Linux 服务器后可能会直接 404所以从一开始就养成规范的命名习惯。写在最后的一些经验这类“SpringBootVue 小区购物系统平台”的毕设项目从拿到源码到真正吃透关键不在于背代码而在于把业务链路和技术选型的道理讲通。我实际操作中发现事务、权限、库存扣减这三块是答辩老师最喜欢深挖的也是你能和其他同学拉开差距的地方。哪怕代码是参考网上开源改的只要你能把状态机流转画出来、把扣库存的 SQL 设计逻辑讲明白这个项目就算真正“属于你”了。最后再分享一个小技巧在项目根目录准备一个 docs 文件夹里面放 README、接口文档、SQL 脚本说明再写一个一页纸的“项目亮点说明”把特殊业务场景的处理逻辑列出来。答辩演示时老师往往没有耐心翻完整个项目一份清晰的文档能让他在三分钟内理解你做了什么、怎么做、为什么这样做这个印象分比多写两个页面更实在。