一套基于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张核心业务表表关系统一做了梳理不复杂但覆盖了商城完整闭环。表名核心字段关键作用userid, username, password, nickname, avatar, status用户登录与基础信息categoryid, name, parent_id, sort商品分类支持二级分类productid, category_id, name, cover, images, price, stock, sales, status商品主信息cartid, user_id, product_id, quantity, checked购物车数据addressid, user_id, receiver, phone, province, city, detail收货地址orderid, order_no, user_id, total_amount, status, address_id, create_time订单主表order_itemid, order_id, product_id, product_name, product_image, price, quantity订单快照明细bannerid, image, url, sort, status首页轮播图commentid, 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, ListCartVO 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参数里比如?categoryId2sortpriceorderdesc。把条件写在路由参数里有省事的好处用户在列表页刷新页面筛选条件不会失效因为浏览器地址栏就带着这些参数。如果单纯放在组件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.00008: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加useUnicodetruecharacterEncodingutf8这里重点说一下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%面试聊项目经历的时候也比只背八股文有用得多。最后再分享一个小技巧这类项目的源码包通常都带着完整的接口文档拿到手之后不要急着看代码先把接口文档从头到尾过一遍对整体功能有个概念然后再按登录 → 商品 → 购物车 → 订单这条主链路去读代码。顺着业务链路读代码比按文件顺序扫、点开哪个看哪个高效得多也能更清晰地把项目核心逻辑记住答辩演示的时候讲出来才能一鼓作气、思路连贯。