一套基于SpringBoot、Vue和Layui的动漫商城管理系统，在Java Web方向里属于比较典型的商用形毕设选题。说典型，是因为它覆盖了Web开发中最常用的技术栈和业务场景：前后端分离、用户鉴权、商品展示、购物车、订单流转、后台管理。我拿到这套项目源码之后，把它的SQL脚本、接口文档和前后端代码完整过了一遍，也自己搭环境跑通了。下面我把这套项目的设计思路、核心实现和踩坑经验整理出来，给正在做商城类毕设或者想入门前后端分离开发的朋友一份参考。
1. 项目概述与技术选型思路
1.1 为什么选SpringBoot + Vue + Layui这套组合
我见过太多毕设一上来就选一堆自己都没用过的高大上框架，结果两个月都搭不出一个完整页面。这套项目选的是SpringBoot 2.x + Vue 2.x + Layui的组合，仔细想想，这个选型在毕设场景里其实非常聪明。
SpringBoot现在已经是Java Web开发的事实标准，不用像老SSH那样写一堆XML配置，内嵌Tomcat后一个jar包直接跑起来。对毕设来说，SpringBoot还有个特别大的优势：面试官和答辩老师都认，答辩时被问到"你的框架是什 么"的时候，不需要解释那些冷门框架是什么、为什么用，直接把SpringBoot的主流特性摆出来就行。而且SpringBoot的自动装配机制让项目开发效率明显提升，开发周期能比SSM短不少。
Vue负责商城主站的前端交互。商城页面的特点是动态内容多、状态变化频繁，比如搜索筛选、加入购物车、结算页的价格联动。用Vue响应式的数据绑定来做，页面更新根本不 用手动操作DOM，代码量可以降低一个量级。Vue的组件化结构也方便把头部导航、商品卡片、分页条这些复用模块抽出来。
Layui则负责后台管理端。这可能是很多不熟悉Layui的人第一时间会疑惑的地方，其实把这两者放在一起一点也不冲突。Layui是个经典的模块化UI框架，表单、表格、弹层、日期选择器这些后台管理页面高频使用的组件都非常成熟，风格统一、中文文档友好。管理端本身交互简单、功能固定，用Layui快速拼出来比用Vue写一套完整管理界面效率高得多。实测下来，管理端的页面量大概只有商城主站的1/3，用Layui能在两个工作日内搞定。
1.2 双前端架构的实际分工
这套项目采用了前后端分离架构，但前端拆成了两个入口：用户访问的商城主站和运营使用的管理后台。
商城主站是Vue应用，由vue-router管理页面路由，vuex或本地状态管理购物车与用户登录状态，axios负责和后端交互。它面对的是普通消费者，体验要求高：页面切换流畅、商品列表加载不能卡顿、购物车操作要即时反馈。Vue响应式和组件化刚好满足这些要求。
管理后台是Layui应用，直接以后端返回的HTML加Layui前端组件渲染，走的是比较传统的开发和部署模式。管理员用它维护商品、处理订单、管理用户和轮播图。后台页面追求的是"能用、好用、不容易出错"，Layui表格的分页刷新、表单的参数校验、弹层的交互逻辑都已经内置，不用自己造轮子。
这种双前端设计有个很现实的好处：时间有限的情况下，不需要在两个前端体系里都投入对等的精力。Vue页面做用户核心流程体验，Layui页面快速覆盖管理功能，同时保持后端对两种前端都提供统一的RESTful接口。
1.3 功能模块划分
从功能上看，这个商城主站分为面向用户和面向管理员两块。
用户侧：
- 注册与登录，支持JWT token鉴权，登录后可以修改个人信息
- 商品分类展示，按动漫周边、手办、衣服等品类区分
- 商品详情页，展示图片、价格、库存、描述
- 购物车管理，支持添加、修改数量、删除、批量结算
- 订单管理，创建订单、支付模拟、查看订单状态、确认收货
- 个人中心，展示头像、昵称、历史订单
管理员侧：
- 商品管理：添加、下架、修改商品信息，上传商品图片
- 分类管理：维护商品目录
- 订单管理：查看所有订单，修改订单状态（发货、完成、取消）
- 用户管理：查看注册用户，启用或禁用账户
- 轮播图管理：维护首页轮播内容
从答辩和评分角度来看，这套功能规模拿捏得比较合适，既有完整业务链路，又不至于让人陷进复杂的分布式、高并发陷阱里。
2. 数据库设计与SQL脚本的核心逻辑
2.1 表结构总览与关系梳理
拿到SQL脚本后我第一件事是把表结构全部过了一遍。这套项目共用9张核心业务表，表关系统一做了梳理，不复杂但覆盖了商城完整闭环。
| 表名 | 核心字段 | 关键作用 |
|---|---|---|
| user | id, username, password, nickname, avatar, status | 用户登录与基础信息 |
| category | id, name, parent_id, sort | 商品分类，支持二级分类 |
| product | id, category_id, name, cover, images, price, stock, sales, status | 商品主信息 |
| cart | id, user_id, product_id, quantity, checked | 购物车数据 |
| address | id, user_id, receiver, phone, province, city, detail | 收货地址 |
| order | id, order_no, user_id, total_amount, status, address_id, create_time | 订单主表 |
| order_item | id, order_id, product_id, product_name, product_image, price, quantity | 订单快照明细 |
| banner | id, image, url, sort, status | 首页轮播图 |
| comment | id, product_id, user_id, content, rating, create_time | 商品评论 |
订单和订单明细拆成两张表是这套设计里我认为最合理的部分。一个订单会有多条明细，按用户维度查订单、按商品维度统计销量都要依赖明细表。很多新手做商城毕设时喜欢把商品冗余到订单里，这个放到下面细说。
2.2 库存、订单明细与数据一致性
商品表里有一个stock字段记录库存，下单时要做扣减。这套项目里采用的方式是：创建订单时先查询库存，判断库存是否足够，然后执行UPDATE product SET stock = stock - quantity WHERE id = ? AND stock >= quantity这种带条件更新的SQL。注意这里的关键点——条件里带上stock >= quantity，这样即使两个请求同时到，数据库层面的行锁也只会让一个更新成功，防止超卖。
订单明细表里直接保存了product_name、product_image、product_price这几个冗余字段。很多人刚学数据库设计时被"规范化"思想影响，觉得任何冗余都不可接受。实际业务场景里，用户下单后商品名称、价格、图片都应该以订单那一刻的快照为准，商品的后续修改不能影响历史订单展示。这不叫设计缺陷，反而是商城类系统的惯例做法。
address表保存收货地址，订单表里只存address_id引用。这个设计的好处是地址可以复用，用户首次下单填写的地址自动存成常用地址。缺点也很明显：如果用户删了地址，订单关联信息会丢失。我在这个项目里采用的做法是订单创建时把地址相关的关键字段也冗余一份到order表的receiver、phone、address_detail字段，既有引用地址的灵活性，又保证订单数据永久可追溯。
2.3 SQL脚本里的细节处理
这套SQL脚本直接导入MySQL就能用，里面有一些值得注意的细节：
字符集统一用了utf8mb4而不是utf8。原因是utf8mb4能完整保存emoji表情和一些生僻字，在商品名称、用户昵称这些字段里非常实用。如果我们用utf8，用户昵称里带个emoji就直接报错或变问号，评论区也容易出问题。
表的主键全部用BIGINT自增，不整UUID那一套，理由很朴素：这是一个单体项目，没有分布式场景，自增主键查询快、索引维护成本低。在SQL脚本里能看到int类型字段都会带上长度，比如int(11)，这个在MySQL 8.0里已经被忽略，但对Oracle、老版本MySQL有兼容意义。
初始化数据脚本里预置了一个管理员账号admin和初始密码，注册用户的密码用的是某种加密方式。注意，一套正规的商城毕设里用户密码绝对不能明文存储，这个项目用了MD5加盐的变体方案。虽然实际生产环境建议BCrypt更稳妥，但在毕设演示层面MD5加盐足够应付，答辩时能说明清楚加盐的作用就可以。
索引部分，除了主键索引外，还在外键关联字段上都加了普通索引，比如product表的category_id、order表的user_id、order_item表的order_id、cart表的user_id。别小看这个细节，商品列表按分类查询、用户查看订单这些高频SQL，没有索引在大数据量下直接全表扫描，慢得没法看。毕设报告里能写出"为高频查询字段建立二级索引"这句话，加分效果很明显。
3. 后端SpringBoot核心实现
3.1 工程结构与请求处理链路
后端工程采用标准的Maven分模块结构（也可以单模块，这个项目以单模块多分包为主），核心包结构如下：
com.animushop ├── config # 跨域、静态资源映射等配置类 ├── controller # 接口层，RESTful风格 ├── service # 业务逻辑层 ├── mapper # MyBatis的Mapper接口 ├── entity # 数据库实体 ├── dto # 传输对象，接收前端入参 ├── vo # 返回对象，拼装后端响应 ├── common # 统一返回体、异常处理、常量 └── util # 工具类，JWT生成解析等请求处理链路是标准的Controller → Service → Mapper → MySQL，重点业务逻辑写在Service层而非Controller层。这个设计在答辩时很值得提：Controller只负责接收参数和返回结果，不写任何业务SQL，有利于单元测试和后期扩展。我在项目里看过不少学生的毕设代码，Controller里直接注入Mapper查数据库的大有人在，一旦业务复杂点代码就全乱了。
3.2 JWT鉴权与登录状态管理
用户登录成功后，后端生成一个JWT token返回给前端。前端把token存到localStorage，之后每次请求在axios拦截器里自动加上Authorization头。后端用一个拦截器统一校验并解析token，解析不到或过期就直接返回401状态码，前端收到401就跳转登录页。
@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和注册接口 String uri = request.getRequestURI(); if (uri.startsWith("/api/user/login") || uri.startsWith("/api/user/register")) { return true; } // 获取token并解析 String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException(401, "未登录"); } // 解析成功后将userId写入request，方便后续使用 Long userId = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", userId); return true; } }token里只存userId和过期时间，不保存敏感信息。这样每个接口都能通过request attribute拿到当前操作人ID，购物车和订单相关接口就不需要前端每次都传uid。值得注意的是，放行规则必须同时覆盖用户端和管理端的登录接口，不然上头一开始就会被拦住。
3.3 商品、购物车、订单的业务实现
商品列表接口是比较典型的联表分页查询。前端会传categoryId、keyword、pageNum、pageSize四个参数，后端用MyBatis-Plus的分页插件完成查询。这里有个实现细节值得说：商品列表返回对象VO里除了product表字段外，会把categoryName也带出来，避免前端拿到categoryId还要额外请求一次分类表。这个操作在SQL里用LEFT JOIN关联category表实现，一 次查询返回完整数据，性能比前端多次请求好得多。
购物车接口围绕用户维度设计，核心接口包括：加入购物车、更新商品数量、勾选商品、删除、清空。加入购物车时需要判断当前用户是否已经把这个商品加入过了，如果加过就把数量加一而不是重新插入一条记录。这里判断条件必须是user_id + product_id的唯一组合，防止重复数据。我还看到项目里有个细节：购物车商品勾选状态用checked字段独立保存，结算时只按勾选的商品生成订单。可能有人觉得这个字段多余，但在真实商城应用里"只结算勾选项"是用户高频操作，把勾选状态持久化比临时在前端拼接好得多。
订单模块是业务量最大的部分。创建订单的完整流程是：
校验购物车勾选商品不为空 → 计算总金额 → 校验库存 → 创建order主表记录 → 批量创建order_item明细 → 扣减库存 → 清空勾选的购物车记录 → 返回order信息
@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(Long userId, List<CartVO> checkedItems, Long addressId) { // 1. 计算总金额并校验库存 BigDecimal totalAmount = BigDecimal.ZERO; for (CartVO item : checkedItems) { Product product = productMapper.selectById(item.getProductId()); if (product.getStock() < item.getQuantity()) { throw new BusinessException(500, "商品" + product.getName() + "库存不足"); } totalAmount = totalAmount.add(product.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } // 2. 创建订单主表 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(0); // 0待支付 order.setAddressId(addressId); orderMapper.insert(order); // 3. 创建订单明细并扣减库存 for (CartVO item : checkedItems) { // 冗余商品名称、图片、价格到订单明细 ... ... // 库存扣减带stock >= quantity条件 productMapper.deductStock(item.getProductId(), item.getQuantity()); } // 4. 删除购物车中已结算商品 cartMapper.deleteByIds(checkedItems.stream().map(CartVO::getId).collect(Collectors.toList())); return ...; }整个方法加@Transactional事务注解，任何一步异常都会整体回滚，能大幅减少脏数据。这个方法里的两个细节我会专门写到博客里给准备答辩的人看：一是金额计算全部用BigDecimal，不碰double和float，避免浮点精度问题；二是扣库存带乐观锁条件，防止并发超卖。
3.4 文件上传与图片处理
商品图片上传是管理端使用频率最高的功能之一。项目里使用了SpringBoot对文件上传的内置支持，操作流程：前端Layui的upload组件选文件，后端接收MultipartFile后保存到本地的/static/upload目录，然后通过WebMvcConfigurer配置静态资源映射，让上传的图片可以通过http://localhost:8080/upload/xxx.jpg直接访问。
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); }这里容易踩的坑有两个。第一个是上传文件大小限制，SpringBoot默认单文件支持1MB，商品图片动辄几MB，所以必须配置spring.servlet.multipart.max-file-size和max-request-size。第二个是保存路径问题：如果直接用相对路径，部署方式不同可能就找不到文件了，建议保存时用绝对路径，并且在启动时通过常量或配置文件统一管理上传目录。
4. 前端Vue与Layui页面实现
4.1 Vue商城页面的组件化拆解
Vue商城页面部分按组件拆分为：HeaderNav、FooterNav、ProductCard、CategorySidebar、Pagination、CartPanel等。每个组件都对应一个.vue单文件，模板、脚本、样式放一起，互不干扰。
页面路由配置上，商品列表页、商品详情页、购物车页、结算页、订单列表页、登录注册页各自对应一个路由。由于这些页面多数需要登录态，我在vue-router的全局前置守卫里加了一个判断：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } })这样用户在未登录状态下访问购物车和结算页，会直接被带到登录页，逻辑非常干净。
搜索与筛选这块我重点研究了一下。商品列表页顶部按分类切换，侧边有价格排序和销量排序，这些筛选条件统一维护在路由的query参数里，比如?categoryId=2&sort=price&order=desc。把条件写在路由参数里有省事的好处：用户在列表页刷新页面，筛选条件不会失效，因为浏览器地址栏就带着这些参数。如果单纯放在组件data里，一刷新页面状态就全丢了，体验很差。
4.2 商品详情与购物车交互
商品详情页的数据来源是detail接口返回的ProductVO，包括轮播图、价格、库存、销量和关联的分类名称。用户点击"加入购物车"时，前端做了两件事：调用后端加入购物车接口，同时更新一下头部导航栏的购物车角标数量。角标数据通过共享状态管理维护，这样不管在哪个页面登录状态和购物车数量都是全局一致的。
购物车页面的交互稍微复杂点，核心是"勾选联动"：全选复选框、单项勾选、合计费用需要实时计算。Vue的computed属性在这里非常合适——只要data里的checked列表变化，computed自动重新计算合计金额，不需要手写任何事件去刷新DOM。
computed: { checkedItems() { return this.cartList.filter(item => item.checked) }, totalPrice() { return this.checkedItems.reduce((sum, item) => sum + item.price * item.quantity, 0) }, isAllChecked() { return this.cartList.length > 0 && this.checkedItems.length === this.cartList.length } }4.3 管理后台与Layui的组合方式
管理后台侧用Layui的典型组合是：layout布局 + tree菜单 + table表格渲染 + layer弹层表单。页面的主结构是一个左侧菜单、右侧内容区的布局。点击菜单时用Layui的table模块重新渲染对应数据。
商品管理页是这个后台里最有代表性的一页，它的实现思路是：
- 顶部是搜索工具栏：商品名称输入框和"搜索""添加商品"按钮
- 中间是table表格：展示商品缩略图、名称、价格、库存、上下架状态、操作列
- 操作列有：编辑、上架/下架、删除
- 新增和编辑共用一个layer弹层，弹层里是一个Layuiform表单，包含名称、分类下拉、价格、库存、图片上传
table的自动渲染方式是接管url属性指向后端接口，Layui会自动向接口传page和limit参数，后端返回的JSON结构只要符合Layui约定的{code:0, msg:"", count:100, data:[...]}，表格就能自动分页、自动刷新、自动排序。这个约定结构是前后端协作最关键的一点，很多人在这个环节出问题，就是因为不懂Layui这个数据结构。项目接口文档里专门标注了返回结构要求，算是把坑提前堵住了。
4.4 前后端联调与axios封装
联调阶段前端统一封装了一个request工具，内部基于axios封装，统一做了三件事：自动附加token；统一处理业务错误码，code不为200时自动弹出提示信息；统一处理HTTP 401，收到401时跳转登录页。
service.interceptors.response.use( response => { const res = response.data if (res.code === 401) { router.push('/login') return Promise.reject(new Error('未登录')) } if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { Message.error(error.message || '网络异常') return Promise.reject(error) } )这样每个页面在调用接口时只需要关心业务数据，不需要反复写错误处理代码。
5. 接口文档与核心接口设计
5.1 接口设计规范
项目的接口文档是按RESTful风格整理的，基础路径统一为/api，接口按模块分类，每个接口都标明请求方式、请求参数、返回参数和示例。实际联调过程中，这套接口设计有几个好处：前端使用时查找方便，不需要在几百行代码里翻；后端自测时可以用Postman按文档逐条验证；答辩时可以阐述针对特定业务做接口的语义化设计。
统一返回体我用的是最常见的结构：
{ "code": 200, "message": "操作成功", "data": { "userId": 1, "username": "test" } }code为200表示成功，非200表示业务失败，401表示未登录。前端所有接口都基于这个结构判断，不需要对每个接口单独写一套成功失败判断逻辑。
5.2 核心接口调用示例
商品分页查询接口是最常用的一个，文档中的说明可以整理成表格：
| 接口地址 | GET /api/product/list |
|---|---|
| 请求参数 | categoryId（可选）、keyword（可选）、pageNum、pageSize |
| 返回数据 | { list: [...], total: 100, pageNum: 1, pageSize: 10 } |
| 注意事项 | categoryId不传就查全部分类，keyword不传就是全部商品 |
这个接口的返回结构在文档里会给出字段级别的说明，比如每项包含productId、name、price、cover、stock等。接口文档的完整程度直接决定别人拿着项目能不能快速二次开发，也决定了评委是不是觉得项目"像真实工程"。很多人毕设项目代码本身没问题，文档一塌糊涂，评分就上不去。
创建订单接口的文档则更细致，指定了请求体示例，展示了要从购物车勾选商品和地址传参方式：
{ "cartIds": [1, 2, 3], "addressId": 10 }文档里还会说明创建订单后返回的订单号，以及前端应该用这个订单号跳转到订单详情或支付页面。这种接口之间联动的说明，是接口文档最有价值的部分之一。
5.3 接口设计中常见的坑
在翻这套接口代码时我发现了几处要特别提醒的点。第一个是参数命名前后端不一致。后端入参如果是Long类型userId，前端却传了字符串形式的userId，在SpringBoot的绑定阶段可能因为类型转换失败直接报400。规范做法是接口文档里明确标注参数类型，前端在传参时统一做一次String转Number。
第二个是日期格式。MySQL的datetime类型返回给前端时默认是"2024-05-20T12:30:00.000+08:00"这种ISO格式，前端要显示"2024-05-20 12:30"还得自己格式化。这个项目在Jackson配置里统一指定了LocalDateTime的序列化格式，把默认的ISO格式改成"yyyy-MM-dd HH:mm:ss"，一次配置全局生效，前端拿到就能直接展示，少了非常多的兼容处理。
第三个是DELETE请求传参。很多浏览器和网络库对DELETE请求的body支持并不好，所以设计接口时，删除操作要么用路径参数（DELETE /api/cart/1），要么直接改用POST传id列表。这个项目里删除购物车项用的就是路径参数方式，简单可靠，不会踩浏览器兼容的坑。
6. 常见问题排查与调试经验
6.1 本地运行常见的"第一坑"清单
按照这套项目部署说明，在前端目录依次执行npm install、npm run serve启动Vue服务，后端直接运行SpringBoot的Application主类，再把SQL脚本导入MySQL，理论上就能跑起来。但是实践中几乎没有人能一次跑通，我整理了一下最常遇到的几个问题：
| 问题现象 | 常见原因 | 解决办法 |
|---|---|---|
| 前端npm install报错 | node版本太高或镜像源不通畅 | 使用Node 14/16，设置淘宝镜像源 |
| 后端启动失败，报数据库连接错误 | MySQL没启动或密码不一致 | 核对application.yml里的数据库名、用户名、密码 |
| 接口请求一直404 | 后端没启动成功或前端代理没配置 | 检查vue.config.js里的proxy配置 |
| 图片加载不出来 | 上传目录不存在或映射配置缺失 | 手动创建upload目录并检查静态资源映射 |
| 中文乱码 | MySQL字符集问题 | 数据库连接URL加useUnicode=true&characterEncoding=utf8 |
这里重点说一下Vue开发时的代理配置。Vue项目默认跑在8080端口，后端接口跑在8080端口，端口不同跨域问题就来了。这个项目在vue.config.js里配置了devServer代理，把所有/api开头的请求统一转给后端端口，前端页面自己访问的路径根本感知不到跨域这回事。如果谁在联调时候不想配代理，直接把前端的默认端口改成8080，或者在后端配置CORS过滤器也能解决，但项目规范的做法是配代理，这样生产环境部署时前端构建产物和后端在同域下也完全没冲突。
6.2 排查接口报错的方法论
我调试这个项目时用了一个比较高效的排查方式：先把浏览器F12的Network标签打开，看请求是否正常发出、状态码是多少。如果状态码是500，就去看后端控制台输出的异常堆栈。多数问题要么出在SQL上，要么出在空指针上。
SQL问题常见于联表查询时字段名对不上。比如category表的id字段，在product表的外键叫category_id，在XML里的SQL写JOIN category ON product.category_id = category.id，如果某个字段名拼错了直接报"Unknown column"。这种报错信息很直接，根据提示去SQL里搜索一下就能定位。
空指针则多发生在Service层。比如从request里取userId时没做判空，前端接口确实带了token但解析失败，或者查商品时根据ID没查到数据却直接去getStock()，项目代码里已经统一增加了业务异常抛出机制，遇到这种情况会抛出"商品不存在"，而不是抛出裸的NullPointerException。这个设计我在答辩时大概能多聊两句。
6.3 答辩演示顺序与评委高频问题
整个项目跑通之后，下一步就是答辩演示。我建议的演示顺序是：先展示商城首页（轮播图、商品分类、商品列表），然后注册或登录一个用户，搜索一个关键词，点进详情页加入购物车，再到购物车修改数量并结算下单，接着切到管理后台登录admin账号，查看新增的订单并修改订单状态为已发货。这一条链路走下来，所有核心功能点都覆盖了，评委也能看到完整业务闭环。
评委通常围绕下面几个问题提问，我把答案整理了一下作为参考：为什么要用SpringBoot而不是SSH？说明SpringBoot的自动配置、内嵌容器、生态成熟度优势；为什么要在订单表冗余商品信息？解释快照设计思路，保证历史订单不受商品信息变更影响；SECURITY相关：密码怎么加密的？说明MD5加盐流程；事务哪里用到？说明下单方法上的@Transactional注解，保证库存扣减和订单创建的原子性；分页怎么实现的？说出MyBatis-Plus分页插件以及和前端pageNum/pageSize参数的对应关系。
还有个经常被追问的角度是"如果把项目数据量扩大十倍，哪里会先扛不住"。这个问题不需要太多深度，能说出商品列表查询加Redis缓存、订单表按时间分表这类优化方向就够了。毕设答辩不是企业架构评审，能展示思考过程比给出完美方案更重要。
7. 项目扩展方向与实际开发心得
7.1 可以继续优化升级的点
这套项目跑通之后，如果想在功能上再往上拔一拔，有两条性价比很高的路径。一条是引入Redis缓存热点数据，把商品分类和首页轮播图这类访问频繁但变化少的数据放缓存，降低数据库压力，同时把验证码、token刷新机制也放到Redis里管理。另一条是增加支付模块的模拟实现，哪怕只做一个跳转到模拟支付页再回调改订单状态的闭环，也会让项目的完整度提升一大截，答辩评分差异往往就在这里拉开。
如果技术底子再好一些，可以给自己的项目接入在线支付沙箱环境，用官方提供的模拟支付工具，支付成功后通过异步通知修改订单状态。这个功能一加上，项目的技术亮点就不只是增删改查了，而是覆盖了支付回调、幂等处理、状态机流转这些偏工程实践的领域。
7.2 对后来者的几个实在建议
我给正在做同类项目的朋友几条掏心窝的建议。
第一，开发顺序不要乱。先画好数据库表，再把后端的用户、商品、购物车、订单接口按依赖关系逐一实现，之后再动前端。如果一上来就做Vue页面，API还没定义好，后面返工成本极高。每个人的切入方式不同，但先理清后端的接口清单再去写前端，是前后端分离模式不被工具折腾死的根本。
第二，永远不要忽略异常处理。项目里每个Controller都尽量在Service层定义业务异常，Controller层统一用@RestControllerAdvice捕获然后返回统一的错误JSON。不加异常处理的话，一旦哪天库存为负或者订单重复创建，前端页面永远只看到一堆满屏红色报错，体验没法看。
第三，代码注释的位置比数量重要。在关键业务逻辑上，比如下单的扣库存事务、JWT拦截器的放行规则、文件上传的路径配置，写上三五行注释解释当初为什么这么设计，比自己写一百行"关闭流""设置状态"的废注释有用得多。
第四，做毕设一定要跑通"从SQL到部署"的全过程，数据库导入要会，Maven打包要会，jar包启动要会。很多同学在IDE里点运行一切正常，回宿舍用命令行一跑就各种报错，提前把这套流程走顺，答辩的时候也会有底气得多。
7.3 反复踩坑后得到的数据层与事务经验
项目里订单创建这个方法是整个系统中并发隐患最大的地方。我在连续测试下单功能时发现过一个问题：如果用户在很短的时间内连点两次"提交订单"，购物车数据可能被提交两次，生成两个相同内容的订单。原因在于前端没有对提交按钮做防重复提交，后端也没对同一购物车记录做幂等校验。解决办法就是在创建订单前，根据当前用户ID和购物车勾选的记录生成一个请求唯一标识，后端做幂等判断，或者前端设置一个submitting状态，在请求完成前禁止按钮再次点击。这个细节如果在答辩时被评委问到，能有理有据地答出来会显得很有经验。
另外我必须强调一下事务边界问题。@Transactional默认只能处理RuntimeException触发的回滚，如果方法里try-catch吞掉了异常，事务是不会回滚的。很多学生写的下单方法，库存扣减失败后catch住异常打个日志直接return成功，订单照样生成，库存却不对。所以项目里我给下单方法明确标注了rollbackFor = Exception.class并保持了异常向上抛出，业务异常由全局处理器集中处理。这种看似基础的事务控制细节，实际是数据层安全的关键。
8. 收尾分享
这套项目的完整流程我实际跑完，整体感觉是：哪怕什么代码都不改，直接按文档部署起来，再配合SQL脚本和接口文档完成一轮演示，就已经达到了一个合格Java Web毕设的标准。但真正让它价值最大化的是在跑通这个流程的过程中，把SpringBoot自动装配、JWT鉴权、MyBatis-Plus分页、Vue组件化、Layui表格渲染、事务控制这些平时学完就忘的知识全部串了一遍。
我个人在实际操作中的体会是，毕设项目最难的从来不是某一个单一技术点，而是把它们串起来的工程能力。比如前端一个小小的时间格式问题，背后是后端Jackson序列化配置和前端展示层的协作；订单模块一次看似简单的提交操作，背后是购物车状态、库存扣减、数据一致性、前后端交互四个环节的协同。把这些问题处理明白，哪怕只理解80%，面试聊项目经历的时候也比只背八股文有用得多。
最后再分享一个小技巧：这类项目的源码包通常都带着完整的接口文档，拿到手之后不要急着看代码，先把接口文档从头到尾过一遍，对整体功能有个概念，然后再按"登录 → 商品 → 购物车 → 订单"这条主链路去读代码。顺着业务链路读代码比按文件顺序扫、点开哪个看哪个高效得多，也能更清晰地把项目核心逻辑记住，答辩演示的时候讲出来才能一鼓作气、思路连贯。
