前后端分离商城系统：SpringBoot+Vue3+MyBatis实战解析

前后端分离的商城系统SpringBootVue3MyBatis这套组合这几年几乎成了Java后端面试和毕业设计里的标配。我拿到这套米家商城源码时第一反应是终于不是那种“前端Vue2后端JSP”缝合怪了而是真正按企业级项目习惯拆成了两个独立工程。这套系统覆盖了电商最核心的用户、商品、购物车、订单和后台管理模块数据库用的是MySQLORM选了MyBatis而不是JPA前后端通过RESTful API通信鉴权走JWT。如果你是正在准备Java面试的应届生、想练手完整项目的初级开发或者需要一套能跑通全流程的商城系统做课设/毕设这套源码的参考价值都很高。抛开“能不能直接上线商用”不谈单从学习和二次开发的角度这套项目的结构其实非常符合当下中小型电商系统的典型形态。下面我把整个系统拆开讲从架构设计、技术选型逻辑到数据库表结构、核心接口实现再到运行部署时容易踩的坑全部过一遍。1. 项目整体拆解这套技术栈为什么能扛住商城系统1.1 前后端分离到底“分离”了什么很多初学者对“前后端分离”的理解停留在“前端一个文件夹、后端一个文件夹”实际上这里的分离开的是部署边界和开发职责。前端工程独立运行在Nginx或者Node服务上负责页面渲染、路由跳转、状态管理通过HTTP请求调用后端暴露的接口。后端工程独立运行在Tomcat内嵌容器上只负责业务逻辑、数据持久化和鉴权校验返回JSON数据。两者之间不共享代码连会话都不共享——这就引出了下一个关键点。这套项目没有用传统的SessionCookie方案而是改用JWTJSON Web Token。我在核对源码时发现后端登录接口会生成一个带过期时间的token返回给前端前端把token存在本地存储里每次请求在请求头里带上Authorization: Bearer token后端通过拦截器统一校验。这种方案的优点是后端天然无状态水平扩容时不需要考虑Session同步问题缺点是token的注销和续期需要额外处理。对于商城这种业务token方案利大于弊。1.2 为什么是MyBatis而不是JPA这是我在面试里被问过无数次的问题。JPA/Hibernate走的是ORM实体映射开发效率高但复杂查询、多表关联、动态SQL这些东西写起来反而不够直观而且性能调优门槛高。MyBatis把SQL完全交给你控制SQL怎么写、怎么优化都在掌控之内。这套商城系统里商品列表的筛选条件、订单模块的多表联查、购物车的批量操作如果用JPA的Specification来做代码会绕一大圈。MyBatis的XML文件里直接写关联查询配合where、if这类动态标签一套SQL模板能应对好几种查询组合可读性比JPA硬编码好得多。还有一个现实原因国内大部分Java项目尤其是传统行业的信息化系统用的是MyBatis或MyBatis-Plus。面试官看到你简历写MyBatis起码知道你能适应国内主流技术栈上手项目成本低。1.3 前端选型Vue3的组合式API更适合复杂业务米家商城的前端没有用Vue2的Options API而是全面转向Vue3的组合式APIComposition API。实际开发中我最直观的感受是同一个功能的代码聚合在一起了——数据、方法、计算属性都放在setup里按逻辑分组而不是分散在data、methods、computed各个选项里。商城前端的典型场景是商品详情页一个页面要同时处理商品信息、SKU选择、规格联动、加入购物车、收藏、评价展示多种状态。用Options API时这些状态的逻辑散落在不同代码段维护起来像翻一本没有目录的书。而组合式API可以把每个业务单元的变量和函数写在一个composable文件里页面代码干净得多。这套源码里的前端还用了Vue Router做路由守卫、Pinia做状态管理、Axios做请求封装后端管理端和用户端拆成了两套页面布局整体工程规范度达到了一个小型团队的水准。2. 数据库与后端核心实现权限、商品、订单的设计思路2.1 数据库表结构设计六张核心表这套系统的数据库我数了一下主体是六张核心业务表外加用户扩展信息表。商城系统最忌讳的是表设计得过于复杂动不动十几张表对学习项目来说完全没有必要但也不能省到连订单快照都没有。核心表的结构整理如下表名核心字段说明userid, username, password, phone, avatar用户表密码存的是BCrypt哈希categoryid, name, parent_id, sort_order商品分类表支持两级分类productid, category_id, name, subtitle, main_image, price, stock, status商品表价格用decimal(10,2)cart_itemid, user_id, product_id, quantity, checked购物车表一个用户对多个商品orderid, order_no, user_id, total_price, status, address, create_time订单主表记录订单总金额和收货信息order_itemid, order_id, product_id, product_name, product_image, price, quantity订单明细表存的是商品快照注意order_item的设计这是很多新手容易忽略的点。下单时商品信息必须以快照形式冗余到明细表里而不是下单后实时去查product表。为什么因为商品可能改名、改价、下架如果订单明细只存了一个product_id用户查看历史订单时看到的可能已经不是当时购买的商品信息了。这个字段冗余是有意为之不是设计失误。2.2 用户鉴权链路拦截器JWTThreadLocal我把这套系统的鉴权链路完整跟踪了一遍逻辑非常清晰分四步第一步登录接口校验用户名密码密码用BCrypt的matches方法验证不直接明文比较因为注册时已经用BCrypt哈希处理过。第二步校验通过后生成JWT载荷里只放userId和username密钥放在配置文件中过期时间默认7天。第三步写一个JwtInterceptor实现HandlerInterceptor接口在preHandle里从请求头解析token校验签名和有效期。校验通过就把userId放ThreadLocal方便Controller直接取。第四步注册拦截器配置放行的白名单路径——登录、注册、商品列表、商品详情这些接口不需要鉴权下单、购物车、订单相关的接口全部拦截。这套链路里ThreadLocal的使用挺典型。因为Spring的Controller层处理一个请求时全程都在同一个线程里执行所以ThreadLocal保存用户信息的生命周期正好跟请求绑定。但务必注意用完清理否则Tomcat线程池复用时会出现数据串号的问题。我看了下代码这个项目在拦截器的afterCompletion里做了remove()操作细节处理是到位的。2.3 订单生成事务与编号策略订单模块是商城系统的重头戏这套源码在处理订单创建时有几个值得学的地方下单接口会先根据购物车选中的商品ID列表查出商品信息然后加锁扣库存。这里的扣库存动作需要配合数据库行锁即SELECT ... FOR UPDATE防止并发超卖。同时在Service方法上标注Transactional保证扣库存、创建订单、写明细三个操作要么全部成功要么全部回滚。订单编号用的是时间戳用户ID随机数而不是MySQL自增主键。原因很直接——订单号要对外展示自增ID会暴露业务量也容易被遍历抓取而时间戳随机数的方案足够区分度也不复杂。金额计算统一用BigDecimal从商品单价到购物车小计到订单总价全程没有出现double或float。这个习惯非常关键涉及钱的运算用二进制浮点类型会出现精度丢失0.10.2不等于0.3这种问题在订单金额上一旦出现就是事故。3. 前端工程化与页面实现从零搭建Vue3商城前台3.1 路由守卫与页面骨架Vue3前端的入口结构是典型的商城布局顶部是导航栏左侧是分类树中间是商品卡片列表。路由配置里明确区分了不需要登录即可访问的公开页面首页、商品列表、商品详情和必须登录才能访问的受保护页面购物车、订单列表、结算页、个人中心。这个守卫逻辑写在全局前置守卫router.beforeEach里面每次路由跳转前先检查目标路由的meta.requiresAuth字段如果要求登录而本地没token就强制跳转到登录页并带上redirect参数登录成功后能用router.push(redirect)回到原页面。这个体验细节很多项目不做用户登录完被丢回首页再次找商品要重新导航体验差很多。界面层用的是Element Plus组件库商品卡片、分页器、表单弹窗这些都是通用组件直接引。有同学可能会犹豫“商城项目用现成UI库是不是显得不高级”我的观点正好相反——企业里几乎没人从零写UI组件库Element Plus的表格、表单、对话框、消息提示能省下大量开发时间把精力集中在业务逻辑上这才是工程化的正确姿势。3.2 Pinia状态管理购物车和用户信息的存取这套项目用Pinia替代了Vuex。购物车模块的状态管理是典型场景用户加购一个商品页面上的徽标数字要立即1刷新页面后购物车数据要恢复不能丢。项目里的做法是cartstore里维护一个cartList数组和一个cartCount计算值加购操作通过addToCartaction完成action内部除了更新本地状态还会同步调用后端的购物车接口保证数据持久化。刷新页面时App.vue的onMounted里会调用fetchCartaction重新拉取购物车数据。跟Vuex对比Pinia的API更简洁没有mutations这一层直接改stateTypeScript类型推导也更友好。Vue3项目建议直接选Pinia不用犹豫。3.3 Axios封装请求拦截、响应拦截、错误提示前端请求封装我看得比较仔细项目里把Axios封装成了一个独立的request.js模块干了三件事请求拦截器里从本地存储取token有就自动加到请求头的Authorization字段。不需要每个业务页面手动传token这是最基础也最容易被漏掉的一步。响应拦截器里统一处理业务码。后端返回的JSON格式遵循{ code: 0, data: ..., msg: ... }code为0表示成功。拦截器对非0状态码统一弹出错误提示对HTTP 401统一做强制退出登录并跳转登录页的操作。业务代码里就不需要每个请求都写try-catch和错误分支了。文件上传接口单独走了一个上传实例不设全局拦截器因为文件上传的返回结构和普通JSON接口不一样。这些细节说明项目作者是真的调试过各种边角场景。4. 项目运行避坑环境、联调与部署问题实录4.1 环境准备JDK版本、MySQL8、Node版本我先说结论这套项目跑起来需要JDK 8推荐JDK 8或11、MySQL 8.0、Node.js 14推荐16或18。我用的是Windows 10 JDK 8 MySQL 8.0 Node 16的环境全程没有遇到版本冲突。MySQL这里容易踩一个SSL连接警告的坑。MySQL 8.0默认开启SSL控制台会刷WARN: Establishing SSL connection without servers identity verification...。如果你嫌烦可以在application.yml的数据库连接串后面加上useSSLfalseserverTimezoneAsia/Shanghai。这个serverTimezone参数不要省MySQL 8.0的时区默认是UTC不加的话CST时间传到Java里会差8个小时。数据库脚本执行时注意编码。我建议在Navicat里用utf8mb4字符集执行SQL文件这样商品的中文描述、emoji符号都不会乱码。MySQL的命令行窗口直接执行有时会因为默认latin1编码导致中文变成问号。4.2 后端启动Maven依赖与端口冲突导入后端工程时我建议直接用IDEA打开pom.xml等Maven把依赖全部拉取完再启动。国内网络环境下首次拉依赖可能很慢如果等了很久没反应检查Maven的settings.xml是不是配了阿里云镜像。端口方面后端工程默认配置的是server.port8080。如果你本机装了其他服务占用了8080启动会报端口冲突改application.yml里的端口号就行。但注意改动端口后前端的Axios请求baseURL要同步改否则会请求到错误地址白屏加控制台报网络错误。前端工程启动命令是标准的npm install npm run devVite默认跑在5173端口访问http://localhost:5173进前台页面后台管理端可能是独立的登录入口要看路由配置。4.3 联调阶段最容易翻车的三个点第一个是跨域。前端的Vite开发服务器跑在5173后端的接口在8080两者端口不同必然触发浏览器跨域机制。解决方式有几种后端加CrossOrigin、写CORS配置类、前端Vite配代理。这套源码的做法是后端全局CORS配置类前端不做代理。如果你在生产环境用Nginx部署直接把前端的/api请求反向代理到后端服务地址就能规避大部分跨域问题。第二个是MyBatis的Mapper绑定错误。报错信息通常是Invalid bound statement (not found)。这个问题的根源是Mapper接口和XML文件没对应起来常见原因有三个XML文件的namespace没写成接口的全限定名XML里的id没有和接口方法名一致编译后XML文件没有被打包进去。如果是Maven项目需要在pom.xml的build标签里把src/main/resources下的XML文件一并打包或者把XML放在和Mapper接口同包结构下。这套项目是放在同包结构下所以导入IDEA时别把XML文件漏了。第三个是数据库表名和实体类字段的驼峰映射。MySQL的习惯是下划线命名product_nameJava实体的习惯是驼峰命名productName。MyBatis默认是不能自动映射的需要在application.yml里开启mybatis: configuration: map-underscore-to-camel-case: true这个配置如果是关闭的你会发现SQL查出来的数据一堆字段是null排查半天最后发现是映射问题。4.4 静态资源与图片上传的目录陷阱商品图片上传功能是这个项目里很容易被忽略但实际很影响体验的模块。本地上传模式下图片存的路径如果是绝对路径比如D:/upload/那么项目换一台机器部署或者打包成JAR运行后这个路径就不存在了要么创建目录要么换个路径。我用java -jar运行后端时遇到过一次图片访问404最后排查发现是图片存的绝对路径跟后端服务的静态资源映射路径没有对齐。如果你也打算二开这套项目建议把上传目录改成相对路径并给SpringBoot配置静态资源映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }这样前端的图片URL写成/upload/xxx.jpg就能正常访问。5. 这套源码还能怎么改性能优化与功能扩展思路5.1 缓存给商品列表加个Redis当前项目里商品列表是每次请求都直接查MySQL的数据量小的时候完全没有问题。但如果未来商品数据量到几万甚至几十万条频繁查询热点商品列表会对数据库造成不必要的压力。二开建议引入Redis做缓存商品列表和商品详情缓存到Redis缓存key按分类ID加页码设计比如product:list:categoryId:page。后端查询时先查缓存缓存没命中再查数据库查到后回填缓存并设置过期时间。商品更新或库存变动时主动删除对应缓存保证数据一致性。这个改动不复杂但面试时聊到“Redis在项目中的应用”就有真实场景可以讲了。5.2 登录放Token失效与多端登录控制当前的JWT方案登录后token的有效期是7天到期后用户需要重新登录。这个机制对商城系统来说可以接受但如果想做得更完善可以考虑加RefreshToken机制短期的AccessToken用来访问业务接口长期的RefreshToken用来续期。RefreshToken存储到Redis里可以实现主动失效——用户修改密码或退出登录时删除令牌强制该账号的token失效。多端登录控制也可以通过Redis实现一个账号的token存成一个key新登录顶掉旧登录每次都从Redis取当前有效token做校验。5.3 ES索引商品搜索目前的商品搜索走的是MySQL的LIKE %keyword%数据量小没问题但拿这个项目去面试时你可以自然地提一句“MySQL模糊搜索无法使用索引数据量大的时候性能会下降”。改进方向是引入Elasticsearch把商品数据同步到ES建立索引搜索走ES商品详情回表查MySQL。这种“搜索引擎数据库”的组合方案是现在电商项目的标配。写在最后我把这套米家商城源码从前到后过了一遍一个很直观的感受是它的模块划分、表结构设计、鉴权逻辑、前端状态管理都和市面上正规培训机构的实战项目思路一致不花哨但很扎实。我个人实际跑项目的过程中印象最深的还是MyBatis这一层——太多的初学者把精力花在死记#{}和${}区别上却忽略了更关键的SQL编写规范和动态SQL的应用。而看一眼这套项目的XML文件你会发现商品搜索和订单联查的SQL写法很有代表性照着写一遍比背十道面试题都有用。找一台机器JDK、MySQL、Node装齐把前后端跑起来下单流程走一遍很多技术点上手就通了。