直接说结论这个题目选得聪明。SpringBoot Vue 是目前 Java Web 方向使用频率最高的前后端分离组合而小区购物系统又是一个业务逻辑非常完整、功能边界清晰的场景——有用户、有商品、有订单、有配送、有权限管理。对毕设来说它既不会因为需求太空而导致不知道做什么也不会因为纯 CRUD 而显得技术含量不足。我见过太多同学选了图书管理系统学生管理系统答辩的时候老师问一句这中间有什么难点全场安静。而购物类系统天然带着订单状态流转、库存扣减、权限校验这些可以深挖的点只要稍微把逻辑做扎实答辩就有话可说。这篇文章我不打算罗列源码而是把整套系统的设计思路、工程结构、数据库落地、前后端联调、部署验证、答辩被追问的高频问题一条线讲清楚。不管你现在是刚开始搭建还是已经写完代码准备写论文都能从里面找到可以直接拿来用的东西。1. 这个项目到底在解决什么问题需求拆解与角色边界1.1 业务场景不是凭空想出来的很多同学做毕设时间紧拿到题目就开始建表写接口写到一半发现功能对不上。其实这种小区购物系统完全可以映射到一个真实场景小区居民线上下单、商户备货、配送员统一配送到指定提货点或者家门口系统承载整个交易闭环。这样理解之后核心需求就非常清晰了。这个题目还有一层特殊背景。在常态化社区治理背景下大规模人员流动受限时无接触购物成为很多小区的刚需。它不是做一个纯电商平台而是做一个半封闭社区内的交易撮合平台。与淘宝、京东那种通用商城相比它的业务范围更小、角色更明确、配送链路更简单非常适合作为毕业设计。1.2 三种角色的权限边界划分整个系统我最建议拆成三类角色这也是数据库设计中用户表和权限表的基础依据。角色核心操作权限范围居民用户浏览商品、加入购物车、下单、在线支付或货到付款、确认收货、评价只能操作自己的购物车和订单商户管理员商品上下架、库存维护、订单接单、订单发货只能管理自己的店铺和商品平台管理员用户管理、商户审核、公告发布、订单总体监控、数据统计全平台数据可见可操作在实际项目里我额外加了一个配送员角色也可以合并到商户管理员下面。如果你项目工期紧张可以先做三个角色如果想让工作量看起来更饱满就拆成四个。配送员只看分配给自己的配送单配送完成后点击确认送达订单状态从待收货变成已完成。这个小小的状态流转意味着你要多写两个接口、多设计一张配送表论文里的功能描述也会更丰富。1.3 订单流转是整个项目的脊梁骨购物类系统最核心的不是商品展示而是订单状态机。我在做这个项目时把订单状态定义为如下链路建议你直接参考待支付 - 待接单 - 待配送 - 待收货 - 已完成 └- 已取消用户支付前/ 已退款售后每个状态迁移对应一个或一组后端接口用户下单成功 - 状态为待支付用户支付或模拟支付- 状态为待接单商户接单 - 状态为待配送配送员接单并送达 - 状态为待收货用户确认收货 - 状态为已完成用户支付前取消订单 - 状态为已取消用户收货后发起退款 - 走售后流程状态为已退款这套状态机是整个系统里最有价值的部分。答辩时老师问你项目的核心逻辑是什么你就把这张图摆出来讲比念 PPT 上那些系统包括用户管理、商品管理、订单管理有说服力得多。1.4 功能清单一次列清楚为了避免开发过程中反复改需求我建议你一开始就按模块列一个完整的功能清单。我当时的清单是这样的用户端注册登录、商品分类浏览、商品关键字搜索、购物车增删改查、提交订单、订单支付模拟、取消订单、确认收货、收货地址管理商户端店铺信息维护、商品新增编辑上架下架、库存管理、接单、发货管理端用户冻结/解冻、商户入驻审核、商品违规下架、公告管理、订单综合查询、销售数据简单报表公共模块首页轮播图、购物车角标、订单状态Timeline展示、手机号脱敏这些功能每一项都不复杂拼在一起就是一个完整的前后端分离系统。关键是**每一项功能都要能对应到具体的表和具体的接口。**功能清单你在选题阶段花半天列清楚后面至少省一周的返工时间。2. 后端工程结构SpringBoot 分层架构与核心接口设计2.1 包结构别乱建参照生产项目的惯例很多毕设代码最大的问题是所有 Controller 堆在一个包里所有 Service 写成一个大类。这个项目我建议按照下面这种经典分层结构组织它也是大部分公司 Java 后端项目的标准风格com.xxx.community ├── controller # 接口入口层只做参数接收和结果封装 ├── service # 业务逻辑层接口定义 impl实现 │ └── impl ├── mapper # 数据访问层继承 BaseMapper ├── entity # 数据库实体类 ├── dto # 前端传入参数对象 ├── vo # 返回给前端的视图对象 ├── config # 配置类跨域、拦截器、Knife4j等 ├── common # 统一返回结果、异常处理、常量 └── utils # 工具类JWT、日期处理等这套结构最大的优点是把接口定义和业务实现拆开controller 层很薄service 层做真正的业务编排。我给你看一个典型的 order 相关代码组织OrderController只负责接收 HTTP 请求参数并调用 serviceOrderServiceOrderServiceImpl处理订单创建、状态流转、库存校验OrderMapper用 MyBatis-Plus 的BaseMapperOrder完成单表 CRUD复杂统计用Select注解写 SQL2.2 统一返回结果前后端联调省一半心前后端分离项目最忌讳每个接口返回结构不一样。我封装了一个ResultT类所有接口统一返回下面这个 JSON 结构{ code: 200, message: 操作成功, data: {} }对应的 Java 代码大致是这样Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }同时写一个全局异常处理器用RestControllerAdvice捕获业务异常和系统异常。这样前端 axios 拦截器只需要判断code是不是 200不是就统一弹出message不用每个接口单独写错误分支。前端 axios 拦截器长这样service.interceptors.response.use( (response) { const res response.data if (res.code ! 200) { Message({ message: res.message || 系统异常, type: error }) return Promise.reject(new Error(res.message)) } return res }, (error) { Message({ message: 网络请求失败, type: error }) return Promise.reject(error) } )2.3 登录鉴权JWT 方案在毕设里的最简落地方式购物系统涉及用户隐私和订单数据登录鉴权是必须的。相比 SessionJWTJSON Web Token天然适合前后端分离也更容易在答辩中展示你对无状态认证的理解。我的实现方案可以精简为三步用户登录成功后后端用SecretKey生成一个 tokentoken 里放用户 id 和角色类型前端把 token 存进 localStorage并在 axios 请求拦截器里放到 Header 的Authorization字段后端写一个拦截器对于需要登录的接口从请求头中解析 token校验通过后把用户信息放入ThreadLocal方便 Service 层随时取当前用户贴一个前端请求拦截器的简化版本service.interceptors.request.use((config) { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config })后端自定义注解RequireLogin 拦截器的方式比较清晰。这个设计在答辩中价值很高因为很多同学的毕设根本没有登录校验或者只在前端做了路由守卫后端接口裸奔。你只要有前端路由守卫 后端接口拦截器双重视角老师就会觉得你对安全是有意识的。2.4 核心接口清单提前定在写代码之前我习惯先用表格把核心接口定下来这样可以同时推进前端页面和后端开发。下面是我当时整理的接口清单节选你完全可以按这个来设计自己的 API功能请求方式路径说明登录POST/api/user/login支持用户名密码登录注册POST/api/user/register注册时默认居民角色商品分页查询GET/api/goods/page支持分类、关键字筛选商品详情GET/api/goods/detail/{id}返回商品信息和库存购物车列表GET/api/cart/list查询当前用户购物车加入购物车POST/api/cart/add参数商品id 数量提交订单POST/api/order/submit从购物车生成订单取消订单POST/api/order/cancel/{orderNo}仅待支付状态可取消商户接单POST/api/order/receive/{orderNo}仅待接单状态可接确认收货POST/api/order/confirm/{orderNo}仅待收货状态可确认订单状态查询GET/api/order/status/{orderNo}返回完整状态流转记录公告列表GET/api/notice/list不分页直接返回订单统计GET/api/admin/order/statistics返回最近7日订单量注意所有路径都带/api前缀方便统一配置跨域和网关代理。后端统一返回Result前端所有请求都走封装好的 axios 实例。2.5 事务和并发一个被毕设忽略但值得做好的点提交订单这个操作我强烈建议加上Transactional。因为下单并不是往订单表插一条数据那么简单它要同时做几件事生成订单主记录、批量插入订单明细、扣减商品库存、清空购物车。任何一个步骤失败都不能让数据库出现订单生成了但库存没扣的不一致状态。Override Transactional(rollbackFor Exception.class) public String submitOrder(OrderSubmitDTO dto) { // 1. 校验商品库存 // 2. 生成订单主记录初始状态为待支付 // 3. 遍历购物车明细生成订单明细 // 4. 扣减库存 // 5. 清空购物车 // 6. 返回订单编号 }关于库存更严谨的做法是用乐观锁UPDATE goods SET stock stock - #{num} WHERE id #{goodsId} AND stock #{num}这条 SQL 本身带了stock #{num}条件在并发下单时数据库会锁行保证不会出现库存超卖。你只要在答辩的时候说出这个细节老师基本不会再刁难你。很多在线商城项目都栽在并发上你提前想了这个问题就是一个实打实的加分项。3. 数据库与 SQL 脚本表结构设计背后的业务逻辑3.1 核心表清单与关系这个项目的数据库我用的是 MySQL 8.0字符集统一设为utf8mb4排序规则用utf8mb4_general_ci。为什么用 utf8mb4因为它能完整存储 Emoji 表情和生僻字购物评价功能容易出现这类字符这一步是为后面省事。核心表包括下面这些user系统用户表包含平台管理员、商户、居民三类goods_category商品分类表goods商品表字段包含分类id、名称、图片、原价、售价、库存、销量、上下架状态cart购物车表字段包含用户id、商品id、数量order订单主表order_item订单明细表delivery配送记录表notice公告表address收货地址表其中最关键的是订单相关两张表的设计。这里我不推荐把订单所有信息全部塞在一张表里。order表存的是订单维度信息订单编号、用户id、商户id、订单总金额、订单状态、支付时间、收货人姓名、联系电话、收货地址order_item表存的是商品维度信息商品id、商品名称、商品图片、单价、数量、小计金额。原因很简单一个订单可能包含多种商品拆成主表和明细表才能避免字段冗余也才能在将来做售后时退单个商品。这种一主多从的表关系是关系型数据库设计的核心思想也是论文里可以展开写的点。3.2 关键表结构实例与字段设计思路订单主表的核心字段设计如下注意我专门加了逻辑删除标记deleted和乐观锁版本号versionCREATE TABLE order ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键id, order_no VARCHAR(64) NOT NULL COMMENT 订单编号业务唯一, user_id BIGINT NOT NULL COMMENT 下单用户id, merchant_id BIGINT NOT NULL COMMENT 所属商户id, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 订单总金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态0待支付 1待接单 2待配送 3待收货 4已完成 5已取消 6已退款, receiver_name VARCHAR(50) NOT NULL COMMENT 收货人姓名, receiver_phone VARCHAR(20) NOT NULL COMMENT 收货人电话, receiver_address VARCHAR(255) NOT NULL COMMENT 收货地址, remark VARCHAR(255) DEFAULT NULL COMMENT 订单备注, pay_time DATETIME DEFAULT NULL COMMENT 支付时间, delivery_time DATETIME DEFAULT NULL COMMENT 配送时间, finish_time DATETIME DEFAULT NULL COMMENT 完成时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除0未删 1已删, version INT NOT NULL DEFAULT 1 COMMENT 乐观锁版本号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_merchant_id (merchant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;我给你拆解几个关键设计点第一order_no必须唯一。我生成订单编号的方式是年月日时分秒 用户id后四位 随机四位比如2025061415304512341287。这样即使并发量上来也不容易出现重复订单号。千万别用数据库自增 id 直接当订单号展示给用户那样不仅不好看也容易暴露平台订单量。第二为什么不直接删数据很多学员在实现用户删除订单时直接DELETE FROM order WHERE id ?。我全部采用逻辑删除也就是 UPDATE 把deleted置为 1。理由有三个一是保留历史数据方便统计和审计二是维护订单表子表如订单明细的一致性成本低三是在电商业务中订单属于关键交易数据物理删除是高风险操作。你在设计其他表的时候也建议遵循这个惯例。第三金额字段类型必须用DECIMAL(10,2)不要用FLOAT或DOUBLE。这是一个经典的精度问题。FLOAT是浮点数在计算总价或者退款金额时会出现 0.1 0.2 0.30000000000000004 这种问题。购物系统涉及钱这种事情一次都不能发生。价格计算一律在 Java 中用BigDecimal不能用double直接加减乘除。3.3 用户表设计为什么把手机号和密码分离考虑用户表user核心字段有这些id、username、password、phone、nickname、avatar、role0平台管理员、1商户、2居民、status0正常、1冻结、create_time、update_time。有几个细节要提醒你password存的一定是 BCrypt 加密后的密文不要用 MD5。MD5 加盐也可以但 Spring Security 自带的 BCryptPasswordEncoder 更省事。在答辩里你可以顺势解释一下 BCrypt 自适应哈希算法的特点顺便说出大多数现代 Web 应用不建议用明文或弱哈希存储密码这一类观点这是很明显的加分行为。手机号建议单独加一个唯一索引。实际业务中登录用户名和手机号都可以作为账号所以要么让username唯一要么让phone唯一。我这里采用username唯一索引登录支持username password同时注册时校验手机号格式。3.4 SQL 脚本交付要做到拿起来就能跑你项目的标题里专门点出了SQL脚本说明数据库脚本是交付的重要部分。我强烈建议你交付的sql文件包含三块内容并且写清楚注释建库建表语句CREATE DATABASE IF NOT EXISTS community_shop DEFAULT CHARACTER SET utf8mb4;然后按依赖顺序建表。所谓依赖顺序就是先建不依赖其他的表再建有外键关联逻辑的表。项目中实际我并没有大量使用数据库外键约束因为技术实践中外键会让删除和迁移变麻烦表间关系我用业务代码来保证。这个点你可以在论文里写清楚。初始数据至少插入一个平台管理员账号、两个测试商户账号、一个普通测试用户账号、若干商品分类、若干商品。如果老师打开你的系统发现是空目录对第一印象的影响很大。我通常还会把不同状态的订单各插入一条方便演示订单流转。演示数据不是所有商品都需要你手动造可以写一个存储过程或者直接用多条 INSERT 语句批量插入几十条商品数据。商品名称可以起得生活化一点比如精选东北大米5kg新鲜上海青500g截图放在论文里更有真实感。注意不要在生产系统中使用外键但在毕设答辩中如果老师问为什么表之间没有外键你不要说我不会用要说外键约束在大型业务系统中会影响扩展性和性能所以这里通过应用层来维护数据一致性。4. Vue 前端与接口联调页面组件化与数据流设计4.1 技术栈选择Vue2 还是 Vue3这个项目标题写的是 Vue具体版本你可以灵活选。我的建议是如果学校课程教的是 Vue2你就用 Vue2 ElementUI如果对前端较熟或者时间充足用 Vue3 ElementPlus Vite 更能展示新技术能力。本质上后端接口是 RESTful 风格的前端不管用什么框架对接方式都差不多。结构上我把前端工程分成三种典型页面类型面向用户的单页应用首页、商品列表、购物车、结算页面向商户的管理页面商品管理、订单处理面向平台管理员的管理后台三种页面对数据的要求不同但都遵循 Vuex 管理用户登录态、Vue Router 做路由切换的思路。4.2 路由与权限控制用meta.roles做前端守卫前端路由守卫是最容易做但很多毕设没做的东西。我的做法是在路由定义里增加meta信息声明哪些角色可以访问{ path: /admin, name: AdminLayout, component: () import(/layout/AdminLayout.vue), meta: { roles: [admin, merchant] }, children: [ { path: goods, name: AdminGoods, component: () import(/views/admin/GoodsManage.vue) } ] }然后在router.beforeEach里校验当前用户角色是否在meta.roles中router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } const user JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.roles !to.meta.roles.includes(user.role)) { next(/403) return } next() })这个机制的配合关系是前端守卫解决页面能不能看到的问题后端拦截器解决接口能不能调的问题。两者缺一不可。很多毕设只做了前端路由守卫然后在接口文档里写需要登录这其实是防君子不防小人。你把两层都说清楚老师就会觉得你有完整的认证-授权思维。4.3 购物车的本地状态与前后端同步策略购物车有两种常见实现方式我在这里要专门讲一下方案A纯前端本地存储购物车数据放 localStorage后端只在下单时接收商品列表。优点是响应快、实现简单缺点是用户换设备购物车就丢了数据不可控。方案B购物车数据完全由后端管理前端每次操作都请求/api/cart/add/api/cart/list。优点是数据持久化换设备不丢缺点是每个操作都要网络请求。我最终采用的是方案B因为毕设要体现数据库设计能力购物车也是一张表而且方案B能更好地支撑购物车角标数量这类交互。用户在商品详情页点击加入购物车前端 POST 后更新 Vuex 里购物车数量购物车页面每次进入都重新拉取/api/cart/list这样数据和后端始终保持同步。购物车页面的删除操作要小心我先调接口删除后端数据成功后更新 Vuex 状态和页面列表而不是先改页面再调接口。这样能保证页面显示和数据库一定是一致的。4.4 订单提交页的联调细节参数校验和金额计算真正容易出 bug 的是结算页。用户从购物车点去结算前端把选中的购物车项cartIds传给后端后端根据这些 id 查出商品和数量在服务端重新计算总金额并校验商品是否在下架状态、库存是否足够。关键逻辑是绝对不要相信前端传过来的总金额。为什么因为前端页面任何人都可以通过调试工具修改。所以我在设计接口时submitOrder接收的参数只有购物车选中项 id 列表和收货地址、备注所有金额计算都在后端完成。前端只做展示。这个设计思路在答辩中也是很有分量的——说明你懂基本的接口安全原则。返回给前端的data我建议包含两个字段orderNo订单编号和totalAmount服务端计算的金额前端拿到这两个字段后跳转到支付确认页。支付页我做的是一套模拟支付流程用户点击确认支付后请求/api/order/pay后端只做状态更新和支付时间写入。这个模拟逻辑在毕设里完全合理你可以在论文中说明因无法接入真实支付渠道本项目实现了模拟支付预留了支付接口扩展能力。4.5 页面联调中的常见问题和排查路径前后端联调时最容易出问题的几类情况我按出现频率给你列一下跨域报错前端访问http://localhost:8080/api后端端口是8080或者9090浏览器直接报 CORS 错误。解决办法是后端写一个 WebMvcConfigurer 配置类允许http://localhost:5173和http://localhost:8080这类地址跨域。开发环境我通常只允许本地端口部署时再放开。日期格式不一致后端返回LocalDateTime默认格式是2025-06-14T15:30:45前端有可能显示成 T 分隔符看起来很奇怪。统一方案是在application.yml里配置 Jackson 的日期格式输出yyyy-MM-dd HH:mm:ss。同时前端也可以做一次全局格式化双保险。字段为 null 导致的前端渲染报错比如商品sales字段是 null页面里直接{{ goods.sales }}会显示空白而不是 0。我前端标准做法是封装一个formatField的 filters 函数后端统一初始化默认值也可以但前后端约定清晰才是根本。分页参数错位MyBatis-Plus 的PageT默认current1、size10前端如果传pageNum和pageSize则不一致。我统一前端参数名也用current和size不要自己发明参数名。这个约定写进接口文档里前后端各留一份。5. 从环境搭建到部署上线的完整实操流程5.1 本地环境版本组合参考版本问题是我见过翻车最多的地方。我用的环境组合比较稳定给你一份参考组件版本说明JDK1.8 或 11建议 1.8兼容性最稳Maven3.6.3没什么特殊要求能用就行Spring Boot2.7.x功能稳定资料多MyBatis-Plus3.5.x用官方 starter 即可MySQL8.05.7 也没问题Node.js16.x 或 18.x对应 Vue 项目的依赖Vue CLI5.x 或 ViteVue3 推荐 ViteSpring Boot 3.x 现在也很多人用但如果你不熟悉 Jakarta 命名空间的变化或者是第一次做毕设我建议稳妥选 2.7.x。这个选择不丢人稳定压倒一切。不要为了追新把整个开发周期搭进去。5.2 后端启动的五个步骤我每次拿到一台新电脑或者给别人远程协助启动项目基本都按这五步排查确认 MySQL 服务已经启动并且用source命令或者 Navicat 运行数据库脚本修改application.yml里的数据库账号密码、端口号确认 Redis 没有使用本系统设计上不引入 Redis减少部署负担在项目根目录执行mvn spring-boot:run或者直接在 IDE 里启动主类用 Postman 访问/api/user/login如果能返回 token说明后端通了整个过程最常出错的地方是application.yml里数据库地址写错。比如localhost:3306写成了127.0.0.1:3306这种看着一样实际可能指向不同的问题。只要启动日志里出现Cannot connect to MySQL之类关键字第一反应就是检查数据库配置。5.3 前端启动与代理配置Vue 项目拿到后先npm install如果没有 node_modules 目录然后启动开发服务器。前端连接后端有两条路一条是直接在后端配置跨域前端请求完整地址http://localhost:8080/api/...。适合本地联调但代码里到处写死端口看着有点土。另一条是用 Vite 或 Vue CLI 的 proxy 代理前端请求/api时自动转发到http://localhost:8080。推荐这种方式因为前端代码里没有具体后端地址部署时更灵活。在vite.config.js里配置如下server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端访问/api/goods/page相当于访问后端的http://localhost:8080/api/goods/page。注意changeOrigin: true这一步很关键它会把请求头里的 Origin 改成目标地址避免部分后端配置下出现跨域问题。5.4 打包上线前端 dist 与后端 jar 的组合毕设通常需要在线演示或者交付给老师运行最好准备打包部署方案。后端打包非常简单mvn clean package -DskipTests然后运行java -jar target/community-shop-0.0.1-SNAPSHOT.jar前端打包npm run build生成dist目录。部署时有两种选择推荐方式是把dist目录里的静态文件放到后端src/main/resources/static下面直接java -jar启动整个系统浏览器访问http://localhost:8080即可。这样不用启动两个进程交付最省事。但要注意如果前端路由用了 history 模式刷新非首页路由会 404解决办法是在后端加一个视图控制器或者在 Spring Boot 里配置转发规则。这个坑毕设很常见提前解决。另一种方式是前端单独部署到 Nginx后端单独跑 jar。这种方式过程更完整Nginx 配置也简单server { listen 80; server_name localhost; root /usr/share/nginx/html/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; } location / { try_files $uri $uri/ /index.html; } }try_files ... /index.html这一行就是解决 history 模式刷新 404 的关键。5.5 接收即死的典型问题端口占用、依赖冲突和磁盘空间我遇到过不少同学卡在这种 5 分钟能解决的问题上端口被占用启动后端显示 Port 8080 was already in use直接执行netstat -ano | findstr 8080Windows或者lsof -i:8080mac/Linux把占用进程 kill 掉。依赖冲突idea 里报ClassNotFoundException或者NoSuchMethodError多数是依赖版本冲突。打开mvn dependency:tree看看哪个 jar 引入了不同版本。实战中最常见是 MyBatis-Plus 和 Spring Boot 版本不匹配尽量都用官方推荐版本组合。磁盘空间不足这个听起来很基础但我真遇到过因为本机 Docker 镜像缓存把磁盘塞满导致 MySQL 启动失败的情况。遇到哪哪不对劲的时候先把磁盘清一清再重新启动服务。6. 答辩现场的加分策略源码、SQL 脚本与接口文档的配合6.1 接口文档别只用 Word建议用在线文档项目标题里特别提到了接口文档我建议你在交付时准备一份可以在线访问的接口文档而不是只给一个 Word。两个快速方案一个是 Knife4j增强版 Swagger引入依赖后启动项目就可以访问/doc.html接口自动生成、可调试演示的时候直接浏览器打开视觉效果和专业感都很好。另一个是在项目里维护 Markdown 版的接口文档用表格列出每个接口的地址、请求参数、响应字段配合截图。我更推荐 Knife4j因为代码即文档这个理念本身就值得在答辩中提一句。6.2 论文与答辩中反复强调的三个为什么答辩时老师最常问的就是系统有哪些亮点。大多数同学的答案是前端用了 Vue后端用了 SpringBoot这不算亮点只是技术选型。我建议你从三个角度准备有深度的回答第一为什么订单状态要设计成状态机而不是简单的一个字段加加减减因为状态机保证了订单流转的合法性比如待支付的订单不能被直接跳转到已完成每一步都有对应的接口和校验逻辑。第二为什么金额运算用 BigDecimal因为浮点数有精度丢失的问题涉及钱必须用高精度类型。这是一个很实际、很具体的工程问题听起来就是真做过项目的人。第三为什么登录用 JWT 而不是 Session因为前后端分离架构中后端接口需要无状态化JWT 把用户身份信息放在加密 token 里前端存储、每次请求携带后端只需要验证签名不需要存储会话信息。同时你要能说出 JWT 的缺点比如 token 无法主动失效如果 token 泄露会有一段时间的安全风险。能说出局限比只会夸更重要。6.3 演示系统的实战脚本答辩演示基本流程建议控制在 10 到 15 分钟演示之前最好准备一份脚本不要现场瞎点。我的推荐顺序是打开用户登录页用测试账号登录展示首页商品列表进入商品详情加入购物车打开购物车确认商品提交订单模拟支付展示订单状态变为待接单切换到商户账号进入商户后台接单、发货切换回用户账号确认收货订单状态变为已完成切到管理员账号展示公告发布、用户管理、订单统计这一套流程完整覆盖了三种角色和订单全链路老师看完基本就明白系统是完整的。演示时最好提前把测试账号、测试商品、数据库初始数据都准备到位不要演示到一半发现购物车是空的。6.4 常见追问的标准回答思路再列几个我预判你会被问到的追问以及推荐回答方向系统安全性怎么保证——答密码明文加密存储接口加了登录拦截器支付金额由后端计算前端不可信。如果有并发下单你怎么处理——答系统在库存扣减上使用带条件的更新语句防止超卖同时订单创建放在事务方法中异常时整体回滚。如果继续深问可以提成本和规模不太适合引入分布式锁但可以讨论用 Redis 分布式锁在集群部署时做进一步扩展。你这个系统和普通电商系统比简化了哪些地方——答没有真正的第三方支付、没有复杂的物流配送系统、没有营销工具但核心交易链路完整并有明确的接口扩展点。诚实说出简化点比被拆台好得多。数据库索引怎么设计的——答订单表对用户 id 和商户 id 加了普通索引订单编号加了唯一索引商品表对分类 id 加了索引用户表对用户名加了唯一索引。理由是查询场景主要在我的订单列表和商户待处理订单列表以及登录场景的用户名查询。6.5 关于交付说明文档的一个实用技巧最后分享一个我写项目笔记时用到的习惯。在 README 或者说明文档里我不仅写如何运行还会建一个问题排查章节把运行过程中最容易踩的坑写进去比如端口冲突、数据库密码不符合、前端代理没生效、JDK 版本问题。做毕设答辩时老师要是现场想跑一下你的项目这一页文档能帮你省下大量解释时间。我自己的真实体会是毕设本质上是你要证明自己具备独立完成一个完整业务系统的能力而不只是把代码跑通。这个小区购物系统项目的核心价值在于它用最简单的技术栈覆盖了一个交易系统应有的完整链路——登录鉴权、商品管理、购物车、订单状态流转、多角色权限、数据统计。把这些点都扎扎实实讲清楚你才能在十几分钟的答辩里让老师感受到你做的事情是有体系、有思考的。把心态放稳。框架和版本永远在变但需求拆解 - 数据建模 - 接口设计 - 前后端联调 - 测试部署这条链路是任何开发工作都逃不过的主线。学的时候多用一点心答辩的时候才真正有话可说。