第一次看到这套“Java Web 手机销售网站系统源码-SpringBoot2Vue3MyBatis-PlusMySQL8.0【含文档】”的项目时我的第一反应不是“又是一个课设”而是“这技术栈组合选得相当标准”。SpringBoot2做后端接口、Vue3做前端页面、MyBatis-Plus操作数据库、MySQL8.0存数据四者组合起来就是一条非常典型的全栈学习路线也是目前企业里轻量级前后端分离项目最常见的形态。这套项目的业务载体是手机销售网站用户能浏览商品、按品牌和分类筛选、加入购物车、下单支付管理员能在后台维护商品、处理订单。核心价值不只是“能跑”而是把一套完整电商闭环从前端页面到后端服务再到数据库表结构全部打通并且附带了部署文档和设计说明。适合三类人一是准备毕业设计的大学生需要一个结构完整、能讲清楚逻辑的项目二是正在学SpringBoot和Vue3的开发者想看看真实项目里这两套技术怎么配合三是想转行做Java开发的人把这类项目吃透积累一个能写进简历的作品。1. 项目整体设计与技术选型思路1.1 这套项目的真正价值点在哪里很多同学拿到的源码只是“能运行”但真正值钱的不是那一堆代码文件而是代码背后的分层组织方式和业务闭环。手机销售网站虽然叫“网站”实际上包含了用户端和管理员端两个完全不同的界面入口前台要的是体验流畅、商品展示清晰、下单流程顺畅后台要的是数据可控、操作直接、权限清晰。这就逼着你做前后端分离。前端Vue3负责渲染页面和交互逻辑后端SpringBoot2提供JSON接口两端通过HTTP协议通信。和旧式JSP项目最大的区别在于页面代码和后端逻辑彻底解耦了改前端样式不用动后端代码后端加接口也不需要前端重新部署页面。这种分离结构直接影响你后面处理登录态、跨域、分页、文件上传这些细节整个项目跑起来之后你能很直观地看到一套商业项目常见的协作方式。另外这套项目附带文档这件事在实际使用中比重很大。我见过太多人拿到源码第一件事就是点运行数据库密码不对、端口被占用、依赖下载失败连报错都看不明白。文档里如果写清楚了数据库脚本位置、启动步骤、默认账号密码能省下一晚上的折腾时间。对你来说这还是一个隐性福利文档本身就是你写毕业设计论文或者项目说明书时最好的参照物。1.2 为什么是SpringBoot2Vue3MyBatis-PlusMySQL8.0这块组合这套技术选型不是拍脑袋定的每一层都有非常明确的理由。SpringBoot2和SpringBoot3之间很多新项目已经开始用3了但这套源码选SpringBoot2很务实。SpringBoot2的生态资料最多网上遇到问题随手就能搜到解决方案各种起步依赖的兼容性也经过了好几轮验证。对于学生和刚转行的开发者来说SpringBoot2踩坑成本远低于SpringBoot3尤其当你需要用到一些老版本第三方库时SpringBoot2的兼容性优势非常明显。Vue3则是前端大趋势。Vue3的组合式APIComposition API让代码组织更灵活逻辑复用比Vue2的Options API舒服太多。配合Vite构建工具开发服务器启动速度是Webpack那一代的几倍改代码热更新也更快。你要是刚从Vue2切过来重点体会两点setup函数里定义响应式数据的写法以及Composition API怎么把一段业务逻辑单独抽成函数。这套项目里的页面如果按Vue3标准写法组织代码会非常清爽每个组件只负责一块职责。MyBatis-Plus是MyBatis的增强工具它没有改变MyBatis的本质只是把单表CRUD和分页这些高频操作从你手里接了过去。就好比MyBatis给了你一把刀MyBatis-Plus直接给你配了刀架和磨刀石你不用每次用刀都重新找一遍。它内部生成了BaseMapper里的通用方法selectById、insert、updateById、deleteById统统是现成的你需要写的SQL只剩下多表关联和复杂查询。对快速开发业务型项目来说这能省下差不多三分之一的工作量。MySQL8.0则是我目前最推荐的数据库版本。和5.7相比8.0默认字符集就是utf8mb4中文字符存储不会出现乱码隐患还支持窗口函数、公用表表达式CTE这些高级特性以后做数据分析类需求也用得上。MySQL8.0的安装和配置我会在第五章详细说这个地方坑不少。1.3 项目模块与典型业务流程手机销售网站的业务从用户视角看就一条主线用户打开首页看到推荐手机点进商品详情页了解参数把手机加入购物车生成订单并支付最后等待发货和收货。这套流程里的核心状态大致是购物车是临时数据删掉就没了订单是永久数据状态从待支付到已支付再到已发货每一步都要落库库存是精确数据每下一单都要扣减不能出现卖超。管理员后台则是另一套逻辑商品管理负责增删改查手机信息包括价格、库存、图片、参数分类管理维护手机品牌和类别保证前台展示有秩序订单管理处理用户提交的订单点击发货后更新状态。用户和管理员看起来在同一个系统里实际权限完全不同所以项目里一定会有一个登录认证模块把身份区分开。别小看这个业务拆解它直接决定了表结构怎么写、接口怎么分、前端页面怎么组织。拿到源码后先画一遍流程图再去看代码比你直接一头扎进Controller里效率高得多。2. 数据库设计与业务模块拆解2.1 核心表结构与字段设计后端最重要的永远是数据库这几乎是所有资深开发者的共识。手机销售网站的表结构按业务域划分通常至少包含下面这些核心表表名作用关键字段user用户信息id, username, password, nickname, phone, avatar, rolebrand手机品牌id, name, logo, sortcategory商品分类id, name, parent_idphone手机商品id, name, brand_id, category_id, main_image, price, stock, sales, status, descriptioncart_item购物车项id, user_id, phone_id, quantity, checkedorder_main订单主表id, order_no, user_id, total_amount, status, pay_time, create_timeorder_item订单明细id, order_id, phone_id, phone_name, price, quantity, imageaddress收货地址id, user_id, receiver, phone, province, city, district, detailbanner首页轮播图id, image, link_url, sort个人体会设计表的时候有三点最容易被新手忽略。第一价格字段必须用decimal而不是doubledouble有精度问题尤其是涉及金额计算时会出现令人恼火的0.30000000000000004这类事故。第二所有表都要加create_time和update_time两个时间字段以后排查数据问题没有时间字段只能靠猜。第三逻辑删除字段deleted加上个默认值0MyBatis-Plus里配好逻辑删除配置删除操作自动变成update语句能保住历史数据。2.2 状态管理别用魔法数字订单状态是电商项目里最典型的状态字段常见做法是用整型数字表示但代码里到处是if status 0这种裸数字就是个灾难。后面前端页面要显示“待付款”“已付款”“已发货”时你根本分不清0到底是什么意思。比较好的做法是建立枚举类把状态定义和代码逻辑解耦。在Java里可以定义一个OrderStatus枚举每个枚举常量包含code和description两个属性前端Vue3里也对应维护一个订单状态常量文件。这样数据库存的是数字接口返回的数字经后端转换后带上状态描述前端页面直接展示描述文字改动状态文案时只改一处就行。我在实际项目里一直强调宁可多写一个枚举类也不要在业务代码里让魔法数字满天飞。2.3 库存与订单的一致性设计手机库存不多了两个用户同时下单买同一部手机库存只有1台结果两张订单都支付成功了。这种“超卖”问题在电商里属于底线bug处理方案在后端一般靠数据库锁。MyBatis-Plus配合MySQL实现起来很简单更新库存时加一个乐观锁字段versionSQL写成就update phone set stock stock - #{num}, version version 1 where id #{id} and version #{oldVersion}执行后受影响行数为0说明版本冲突直接抛出库存不足异常。如果只用Java代码先查库存再减库存中间一定会有并发空隙两个请求同时读到库存1各自减1后写回库存就变成0了。这个问题面试官最爱问怎么防止超卖回答乐观锁或者悲观锁都可以但你要能说出两者的区别。乐观锁适用于冲突较少的场景每次更新都带版本号检查悲观锁用for update直接锁住行记录适用于下单频率高、冲突严重的场景。这套项目里推荐用乐观锁实现成本低性能影响小。3. 后端核心实现SpringBoot2 MyBatis-Plus的正确玩法3.1 分层结构与统一返回体拿到任何一套SpringBoot源码先看它的包结构就能判断出作者水平。常规的分层是Controller、Service、Mapper三层但更讲究一点的项目会加DTO和VO。Controller只负责接收参数和返回结果不含业务逻辑Service层处理具体业务事务也包在这一层Mapper层只跟数据库打交道DTO是接口入参对象VO是接口出参对象。这个分层直接解决的问题是数据库表字段变了不会影响前端接口接口入参变了不会污染数据库实体类。举个例子注册接口只需要username和password两个字段但user表里有几十列如果直接把User实体类作为接收参数多传的字段就存在被恶意赋值的风险。用RegisterDTO做参数接收再在Service里转换成User实体入库安全性好得多。统一返回体也是必须的。后端接口不能成功返回数据、失败返回null这样前端没法统一处理错误提示。定义个Result类结构通常包含code、message、data三个字段配合一个泛型方法Result.success(data)和Result.error(msg)使用。这样后端出任何异常前端都能在axios拦截器里统一弹出错误提示代码体验能提升一截。3.2 MyBatis-Plus少写SQL不代表不关注SQLMyBatis-Plus的BaseMapper接口提供了大量的通用方法你自定义Mapper接口继承它以后CRUD就齐了。但真正要掌握的是条件构造器Wrapper的使用。实际开发里整理商品列表按品牌筛选加按价格排序通过LambdaQueryWrapper写起来非常流畅public PagePhone pagePhones(PhoneQueryDTO dto) { PagePhone page new Page(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapperPhone wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(dto.getBrandId()), Phone::getBrandId, dto.getBrandId()) .like(StringUtils.isNotBlank(dto.getKeyword()), Phone::getName, dto.getKeyword()) .orderByDesc(Phone::getSales); return phoneMapper.selectPage(page, wrapper); }注意eq和like的第一个参数是个boolean条件只有条件成立时才会拼接这条SQL。这种写法可以彻底告别一堆if判断到底要不要加某个查询条件的问题。分页插件记得在启动类里注册MybatisPlusInterceptor加入PaginationInnerInterceptor否则selectPage方法返回的total永远是0这是MyBatis-Plus最经典的坑。但我要强调一点少写SQL不等于不用懂SQL。遇到多表关联、复杂统计时该写Select注解自定义SQL还是一样要写。MyBatis-Plus擅长的是单表和简单查询不是银弹。面试官如果问MyBatis-Plus底层原理你要能说到点子上它是通过动态代理为Mapper接口生成代理对象在selectList、selectPage这些方法执行前用JSqlParser解析SQL自动拼接where条件和分页参数。再深入一层它就是拼SQL所以逻辑删除、乐观锁本质都是往SQL上附加条件和片段。3.3 鉴权、异常处理与事务用户登录模块不用管用户角色的话用JWT做一个无状态鉴权就够了。流程是用户登录成功后后端用用户的id和username生成JWT token返回给前端前端把token存到localStorage里axios请求拦截器在每次请求头带上Authorization: Bearer token后端加一个拦截器解析token解析失败就返回401状态码让前端跳回登录页。SpringBoot2里集成JWT很简单用到jjwt库工具类里封装生成token和解析token两个方法。但这个方案有一个问题JWT是无状态的服务端没法主动让一个token失效。如果要做真正严格的权限控制建议后续改成Sa-Token或Spring Security这两者对登录状态和权限模型的支持都完善得多。全局异常处理是一个常被忽略但非常重要的组件。如果你不在全局捕获异常数据库报错信息会直接暴露给前端既难看又不安全。定义一个RestControllerAdvice类用ExceptionHandler分别处理业务异常和通用异常返回统一的Result错误结构。业务异常可以自己定义个BizException包含错误码和错误信息密码错误、库存不足这类情况直接throw new BizException(库存不足)全局处理器自动转成JSON返回。事务一般加在Service层订单生成这个方法典型需要Transactional先校验库存、扣减库存、创建订单、清空购物车任何一步失败都要全部回滚。Spring事务失效的几个常见情况必须记牢同类内部方法调用不走代理比如一个类里的方法A调用方法BB上的Transactional不会生效方法不是public时也不会生效自己捕获了异常没抛出去事务也会认为一切正常直接提交。出现订单生成成功但库存没扣减先检查这三条。4. 前端Vue3实现与前后端联调4.1 Vite Vue3工程初始化与目录规划Vue3项目目前主流是Vite构建创建命令是npm create vitelatest选择Vue框架配套的JavaScript或TypeScript模板。工程目录一般这样规划views目录放页面组件components目录放公共组件router目录放路由配置store目录放Pinia状态管理api目录放每个模块的接口请求函数utils目录放axios实例和工具函数assets目录放静态资源。和Vue2时代相比Vue3最大的变化是setup语法糖配合
SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0手机销售网站全栈实战解析
第一次看到这套“Java Web 手机销售网站系统源码-SpringBoot2Vue3MyBatis-PlusMySQL8.0【含文档】”的项目时我的第一反应不是“又是一个课设”而是“这技术栈组合选得相当标准”。SpringBoot2做后端接口、Vue3做前端页面、MyBatis-Plus操作数据库、MySQL8.0存数据四者组合起来就是一条非常典型的全栈学习路线也是目前企业里轻量级前后端分离项目最常见的形态。这套项目的业务载体是手机销售网站用户能浏览商品、按品牌和分类筛选、加入购物车、下单支付管理员能在后台维护商品、处理订单。核心价值不只是“能跑”而是把一套完整电商闭环从前端页面到后端服务再到数据库表结构全部打通并且附带了部署文档和设计说明。适合三类人一是准备毕业设计的大学生需要一个结构完整、能讲清楚逻辑的项目二是正在学SpringBoot和Vue3的开发者想看看真实项目里这两套技术怎么配合三是想转行做Java开发的人把这类项目吃透积累一个能写进简历的作品。1. 项目整体设计与技术选型思路1.1 这套项目的真正价值点在哪里很多同学拿到的源码只是“能运行”但真正值钱的不是那一堆代码文件而是代码背后的分层组织方式和业务闭环。手机销售网站虽然叫“网站”实际上包含了用户端和管理员端两个完全不同的界面入口前台要的是体验流畅、商品展示清晰、下单流程顺畅后台要的是数据可控、操作直接、权限清晰。这就逼着你做前后端分离。前端Vue3负责渲染页面和交互逻辑后端SpringBoot2提供JSON接口两端通过HTTP协议通信。和旧式JSP项目最大的区别在于页面代码和后端逻辑彻底解耦了改前端样式不用动后端代码后端加接口也不需要前端重新部署页面。这种分离结构直接影响你后面处理登录态、跨域、分页、文件上传这些细节整个项目跑起来之后你能很直观地看到一套商业项目常见的协作方式。另外这套项目附带文档这件事在实际使用中比重很大。我见过太多人拿到源码第一件事就是点运行数据库密码不对、端口被占用、依赖下载失败连报错都看不明白。文档里如果写清楚了数据库脚本位置、启动步骤、默认账号密码能省下一晚上的折腾时间。对你来说这还是一个隐性福利文档本身就是你写毕业设计论文或者项目说明书时最好的参照物。1.2 为什么是SpringBoot2Vue3MyBatis-PlusMySQL8.0这块组合这套技术选型不是拍脑袋定的每一层都有非常明确的理由。SpringBoot2和SpringBoot3之间很多新项目已经开始用3了但这套源码选SpringBoot2很务实。SpringBoot2的生态资料最多网上遇到问题随手就能搜到解决方案各种起步依赖的兼容性也经过了好几轮验证。对于学生和刚转行的开发者来说SpringBoot2踩坑成本远低于SpringBoot3尤其当你需要用到一些老版本第三方库时SpringBoot2的兼容性优势非常明显。Vue3则是前端大趋势。Vue3的组合式APIComposition API让代码组织更灵活逻辑复用比Vue2的Options API舒服太多。配合Vite构建工具开发服务器启动速度是Webpack那一代的几倍改代码热更新也更快。你要是刚从Vue2切过来重点体会两点setup函数里定义响应式数据的写法以及Composition API怎么把一段业务逻辑单独抽成函数。这套项目里的页面如果按Vue3标准写法组织代码会非常清爽每个组件只负责一块职责。MyBatis-Plus是MyBatis的增强工具它没有改变MyBatis的本质只是把单表CRUD和分页这些高频操作从你手里接了过去。就好比MyBatis给了你一把刀MyBatis-Plus直接给你配了刀架和磨刀石你不用每次用刀都重新找一遍。它内部生成了BaseMapper里的通用方法selectById、insert、updateById、deleteById统统是现成的你需要写的SQL只剩下多表关联和复杂查询。对快速开发业务型项目来说这能省下差不多三分之一的工作量。MySQL8.0则是我目前最推荐的数据库版本。和5.7相比8.0默认字符集就是utf8mb4中文字符存储不会出现乱码隐患还支持窗口函数、公用表表达式CTE这些高级特性以后做数据分析类需求也用得上。MySQL8.0的安装和配置我会在第五章详细说这个地方坑不少。1.3 项目模块与典型业务流程手机销售网站的业务从用户视角看就一条主线用户打开首页看到推荐手机点进商品详情页了解参数把手机加入购物车生成订单并支付最后等待发货和收货。这套流程里的核心状态大致是购物车是临时数据删掉就没了订单是永久数据状态从待支付到已支付再到已发货每一步都要落库库存是精确数据每下一单都要扣减不能出现卖超。管理员后台则是另一套逻辑商品管理负责增删改查手机信息包括价格、库存、图片、参数分类管理维护手机品牌和类别保证前台展示有秩序订单管理处理用户提交的订单点击发货后更新状态。用户和管理员看起来在同一个系统里实际权限完全不同所以项目里一定会有一个登录认证模块把身份区分开。别小看这个业务拆解它直接决定了表结构怎么写、接口怎么分、前端页面怎么组织。拿到源码后先画一遍流程图再去看代码比你直接一头扎进Controller里效率高得多。2. 数据库设计与业务模块拆解2.1 核心表结构与字段设计后端最重要的永远是数据库这几乎是所有资深开发者的共识。手机销售网站的表结构按业务域划分通常至少包含下面这些核心表表名作用关键字段user用户信息id, username, password, nickname, phone, avatar, rolebrand手机品牌id, name, logo, sortcategory商品分类id, name, parent_idphone手机商品id, name, brand_id, category_id, main_image, price, stock, sales, status, descriptioncart_item购物车项id, user_id, phone_id, quantity, checkedorder_main订单主表id, order_no, user_id, total_amount, status, pay_time, create_timeorder_item订单明细id, order_id, phone_id, phone_name, price, quantity, imageaddress收货地址id, user_id, receiver, phone, province, city, district, detailbanner首页轮播图id, image, link_url, sort个人体会设计表的时候有三点最容易被新手忽略。第一价格字段必须用decimal而不是doubledouble有精度问题尤其是涉及金额计算时会出现令人恼火的0.30000000000000004这类事故。第二所有表都要加create_time和update_time两个时间字段以后排查数据问题没有时间字段只能靠猜。第三逻辑删除字段deleted加上个默认值0MyBatis-Plus里配好逻辑删除配置删除操作自动变成update语句能保住历史数据。2.2 状态管理别用魔法数字订单状态是电商项目里最典型的状态字段常见做法是用整型数字表示但代码里到处是if status 0这种裸数字就是个灾难。后面前端页面要显示“待付款”“已付款”“已发货”时你根本分不清0到底是什么意思。比较好的做法是建立枚举类把状态定义和代码逻辑解耦。在Java里可以定义一个OrderStatus枚举每个枚举常量包含code和description两个属性前端Vue3里也对应维护一个订单状态常量文件。这样数据库存的是数字接口返回的数字经后端转换后带上状态描述前端页面直接展示描述文字改动状态文案时只改一处就行。我在实际项目里一直强调宁可多写一个枚举类也不要在业务代码里让魔法数字满天飞。2.3 库存与订单的一致性设计手机库存不多了两个用户同时下单买同一部手机库存只有1台结果两张订单都支付成功了。这种“超卖”问题在电商里属于底线bug处理方案在后端一般靠数据库锁。MyBatis-Plus配合MySQL实现起来很简单更新库存时加一个乐观锁字段versionSQL写成就update phone set stock stock - #{num}, version version 1 where id #{id} and version #{oldVersion}执行后受影响行数为0说明版本冲突直接抛出库存不足异常。如果只用Java代码先查库存再减库存中间一定会有并发空隙两个请求同时读到库存1各自减1后写回库存就变成0了。这个问题面试官最爱问怎么防止超卖回答乐观锁或者悲观锁都可以但你要能说出两者的区别。乐观锁适用于冲突较少的场景每次更新都带版本号检查悲观锁用for update直接锁住行记录适用于下单频率高、冲突严重的场景。这套项目里推荐用乐观锁实现成本低性能影响小。3. 后端核心实现SpringBoot2 MyBatis-Plus的正确玩法3.1 分层结构与统一返回体拿到任何一套SpringBoot源码先看它的包结构就能判断出作者水平。常规的分层是Controller、Service、Mapper三层但更讲究一点的项目会加DTO和VO。Controller只负责接收参数和返回结果不含业务逻辑Service层处理具体业务事务也包在这一层Mapper层只跟数据库打交道DTO是接口入参对象VO是接口出参对象。这个分层直接解决的问题是数据库表字段变了不会影响前端接口接口入参变了不会污染数据库实体类。举个例子注册接口只需要username和password两个字段但user表里有几十列如果直接把User实体类作为接收参数多传的字段就存在被恶意赋值的风险。用RegisterDTO做参数接收再在Service里转换成User实体入库安全性好得多。统一返回体也是必须的。后端接口不能成功返回数据、失败返回null这样前端没法统一处理错误提示。定义个Result类结构通常包含code、message、data三个字段配合一个泛型方法Result.success(data)和Result.error(msg)使用。这样后端出任何异常前端都能在axios拦截器里统一弹出错误提示代码体验能提升一截。3.2 MyBatis-Plus少写SQL不代表不关注SQLMyBatis-Plus的BaseMapper接口提供了大量的通用方法你自定义Mapper接口继承它以后CRUD就齐了。但真正要掌握的是条件构造器Wrapper的使用。实际开发里整理商品列表按品牌筛选加按价格排序通过LambdaQueryWrapper写起来非常流畅public PagePhone pagePhones(PhoneQueryDTO dto) { PagePhone page new Page(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapperPhone wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(dto.getBrandId()), Phone::getBrandId, dto.getBrandId()) .like(StringUtils.isNotBlank(dto.getKeyword()), Phone::getName, dto.getKeyword()) .orderByDesc(Phone::getSales); return phoneMapper.selectPage(page, wrapper); }注意eq和like的第一个参数是个boolean条件只有条件成立时才会拼接这条SQL。这种写法可以彻底告别一堆if判断到底要不要加某个查询条件的问题。分页插件记得在启动类里注册MybatisPlusInterceptor加入PaginationInnerInterceptor否则selectPage方法返回的total永远是0这是MyBatis-Plus最经典的坑。但我要强调一点少写SQL不等于不用懂SQL。遇到多表关联、复杂统计时该写Select注解自定义SQL还是一样要写。MyBatis-Plus擅长的是单表和简单查询不是银弹。面试官如果问MyBatis-Plus底层原理你要能说到点子上它是通过动态代理为Mapper接口生成代理对象在selectList、selectPage这些方法执行前用JSqlParser解析SQL自动拼接where条件和分页参数。再深入一层它就是拼SQL所以逻辑删除、乐观锁本质都是往SQL上附加条件和片段。3.3 鉴权、异常处理与事务用户登录模块不用管用户角色的话用JWT做一个无状态鉴权就够了。流程是用户登录成功后后端用用户的id和username生成JWT token返回给前端前端把token存到localStorage里axios请求拦截器在每次请求头带上Authorization: Bearer token后端加一个拦截器解析token解析失败就返回401状态码让前端跳回登录页。SpringBoot2里集成JWT很简单用到jjwt库工具类里封装生成token和解析token两个方法。但这个方案有一个问题JWT是无状态的服务端没法主动让一个token失效。如果要做真正严格的权限控制建议后续改成Sa-Token或Spring Security这两者对登录状态和权限模型的支持都完善得多。全局异常处理是一个常被忽略但非常重要的组件。如果你不在全局捕获异常数据库报错信息会直接暴露给前端既难看又不安全。定义一个RestControllerAdvice类用ExceptionHandler分别处理业务异常和通用异常返回统一的Result错误结构。业务异常可以自己定义个BizException包含错误码和错误信息密码错误、库存不足这类情况直接throw new BizException(库存不足)全局处理器自动转成JSON返回。事务一般加在Service层订单生成这个方法典型需要Transactional先校验库存、扣减库存、创建订单、清空购物车任何一步失败都要全部回滚。Spring事务失效的几个常见情况必须记牢同类内部方法调用不走代理比如一个类里的方法A调用方法BB上的Transactional不会生效方法不是public时也不会生效自己捕获了异常没抛出去事务也会认为一切正常直接提交。出现订单生成成功但库存没扣减先检查这三条。4. 前端Vue3实现与前后端联调4.1 Vite Vue3工程初始化与目录规划Vue3项目目前主流是Vite构建创建命令是npm create vitelatest选择Vue框架配套的JavaScript或TypeScript模板。工程目录一般这样规划views目录放页面组件components目录放公共组件router目录放路由配置store目录放Pinia状态管理api目录放每个模块的接口请求函数utils目录放axios实例和工具函数assets目录放静态资源。和Vue2时代相比Vue3最大的变化是setup语法糖配合
