SpringBoot + Vue前后端分离宠物商城系统完整实战与部署指南

前后端分离的宠物商城项目这段时间前前后后折腾了一个多月从数据库设计到前后端联调再到最终部署上线踩了不少坑也整理出来了一套完整的落地流程。看到不少人都在问SpringBootVue这种前后端分离的商城系统该怎么从零搭起来我把这个项目的完整实现过程梳理了一遍从技术选型到核心模块拆解从数据库设计到部署注意事项尽量写清楚每一步背后的思考方便想动手做类似项目的朋友直接参考。这个项目是个标准的Web宠物商城功能上覆盖了主流的电商闭环用户注册登录、宠物商品浏览与检索、购物车管理、订单创建与支付状态流转、后台管理端对宠物信息和订单的维护。后端用SpringBoot提供RESTful API前端用Vue单页应用做交互界面数据层走MyBatis MySQL这套经典组合。适合正在学SpringBoot和Vue整合、准备做毕业设计或简历项目的人也适合刚进入JavaWeb开发、想搞清楚前后端分离项目到底怎么组织代码结构的同学。1. 项目整体设计与技术选型思路1.1 为什么选择前后端分离架构在做这个系统之前我其实也对比过传统的服务端渲染方案比如直接用Thymeleaf把页面和接口揉在一起。那种方案在小项目里确实开发速度快但一旦牵扯到多端复用、前后端并行开发、后续功能迭代这些场景就非常难受。换到现在这版前后端分离架构后业务逻辑和页面展示被彻底拆开后端只负责输出JSON数据前端只关心数据渲染和交互。实测下来最大的好处是两个人可以并行开发互不干扰前端工程师不用等后端模板后端也不用操心页面长什么样。这种架构对部署环境的要求也更灵活。前端打包出来是纯静态资源扔到Nginx下就能跑后端是独立的SpringBoot服务端口、资源、日志都是自己管后续真要扩展用户端和管理端这种多端场景后端接口直接复用前端另起项目就行不需要动业务代码。1.2 技术栈选型背后的考量技术选型上我坚持用了SpringBoot 2.7 Vue 2 MyBatis MySQL 8.0这套组合没有刻意追新版本。先说SpringBoot2.7版本是目前生产环境里用得最多的稳定版本之一资料多、踩坑记录全不管遇到什么问题基本都能搜到现成答案。如果选最新的SpringBoot 3.x虽然性能更好但很多老版本的第三方组件兼容性需要额外处理对新手来说没必要让自己卡在环境问题上。Vue同样选的是2.6版本搭配Vue Router和Vuex。Vue 3虽然已经是主流但Vue 2的生态积累和教程数量是最大的做项目时查资料方便。这套选型本身就是拿来做学习项目和普通商用场景的稳定性比版本新旧更重要。MyBatis在持久层这块的优势是SQL可控。商城系统里有大量复杂的查询场景比如按宠物分类筛选、按价格区间过滤、订单列表多条件组合查询用MyBatis写动态SQL非常顺手。对比过JPA那种全自动ORM在简单CRUD上确实舒服但一旦SQL变得复杂排查问题和SQL优化反而更费力。MyBatis把SQL都放在Mapper文件里直观可控对商城这类业务来说更实用。MySQL 8.0在事务支持、窗口函数、JSON类型这些方面的能力都比5.7强不少虽然商城业务本身用不到太高级的特性但后续真要加数据统计、复杂报表功能8.0的上限明显更高省得到时候再折腾升级。1.3 核心业务模块拆解这个宠物商城拆下来主要有这些模块用户模块注册、登录、Token鉴权、个人信息维护。登录之后的所有操作都依赖Token来识别用户身份。宠物商品模块宠物列表、详情、分类筛选、关键词搜索、上下架管理。前台的搜索和筛选条件会拼到后端SQL里做动态查询。购物车模块加入购物车、修改数量、删除、批量结算。购物车数据是按用户维度存储的未登录状态不能操作。订单模块从购物车生成订单、订单列表、订单详情、取消订单、模拟支付。订单涉及多张表的状态流转是后端事务处理的核心场景。后台管理模块宠物信息的增删改查、订单状态管理、用户管理。前端单独跑在另一个端口和后端共用一套接口。业务模块的边界在设计阶段就要想清楚不然写代码的时候很容易把逻辑堆到一个Service里面。比如购物车和订单之间通过一个转换逻辑来衔接购物车负责维护“用户想买什么”订单负责处理“用户买成了什么”两者之间不该有耦合。2. 数据库设计与核心表结构解析2.1 数据库设计的三条核心思路商城系统的数据库设计是整个项目的底盘设计得好不好直接决定后期写SQL时痛苦不痛苦。我踩过一次坑一开始把宠物信息、宠物图片、宠物分类全塞进一张表结果加分类、加轮播图的时候改表结构改到怀疑人生。后来按照电商系统的标准做法重新梳理核心思路有三条。第一核心实体独立建表不搞大宽表。用户、宠物、分类、订单、订单项、购物车、轮播图这些核心实体各建各的表通过主外键关联起来。第二金额和数量这种关键字段要选对类型金额用DECIMAL(10,2)数量和库存用INT不能用浮点数否则结算时精度会出问题。第三所有表都加上create_time和update_time两个通用字段排查数据问题时没有这两个时间戳会非常被动。2.2 核心表结构详解用户表和宠物商品表是整个项目中要设计清楚的两张基础表。用户表的核心字段包括id、username、password、nickname、phone、avatar、create_time、update_time。这里要注意密码绝对不能明文存储我会在写入数据库之前用BCrypt加密后面登录校验时用BCrypt自带的matches方法做比对安全性上会更可靠。宠物商品表涉及的字段就比较多了。id、pet_name是商品名category_id关联分类表price用DECIMAL(10,2)存单价stock记录库存数量main_image存封面图detail整个HTML字符串展示宠物详情描述再就是sale_count记录销量、status控制上下架状态、create_time和update_time。分类表就简单多了只有id、category_name和sort_order这三个字段后续如果要扩展成多级分类再加parent_id字段就能实现。订单相关的是整个数据库设计的重头戏。订单主表orders里我放了order_no业务订单号、user_id、total_amount、status、address、phone、receiver_name这些字段。订单状态我用整数去表示0表示待支付1表示已支付待发货2表示已发货3表示已完成4表示已取消。用整数存状态的好处是扩展方便而且代码里可以定义常量对应可读性也有保证。订单项表order_item主要记录每个订单里包含的宠物信息包括order_id、pet_id、pet_name、pet_image、price、count、subtotal。这里故意冗余了pet_name和pet_image这两个非必要的字段因为用户下单之后哪怕宠物商品后来下架了或者改名了订单里的历史快照还是不能变。这个设计思路在做商城系统时很关键各表的分工牢牢对应业务主链路后面写Service层逻辑时思路特别顺畅。2.3 表设计里的几个自检点数据库设计完我会自己过一遍这几个自检问题每个表有没有明确的主键有没有留出create_time和update_time金额字段是不是DECIMAL类型表的命名是不是清晰可读订单号是不是唯一的、有没有建立唯一索引用户和订单之间、订单和订单项之间的外键关系是否清晰这些点看似基础但实际项目中很多不合理的表结构都是在这几个小问题上栽跟头的。外部对订单号的生成规则也可以提一下我用的是当前时间戳加随机数组合生成格式类似“20240419103056881234”前段是年月日时分秒后面几位是随机序列保证业务上不会重复。如果要做更高并发场景可以引入雪花算法但个人项目里完全没必要增加这个复杂度。3. 后端接口设计与业务实现细节3.1 SpringBoot项目结构规划后端项目我整体按“controller - service - mapper”三层来组织。controller层只管接参数、调服务、返回结果service层处理实际的业务逻辑包括事务控制mapper层对应MyBatis的数据访问。还要抽出一个common包放统一返回结果、异常处理、Token工具类、配置类这些公共内容避免代码散落各处。目录结构大致是这样的com.petmall ├── controller用户、宠物、购物车、订单、后台管理接口 ├── service接口和实现分开 ├── mapperMyBatis的Mapper接口 ├── entity数据库实体类 ├── dto前端传入的参数对象 ├── vo返回给前端的数据对象 ├── common全局返回、异常、常量、工具类 └── config跨域配置、拦截器配置等这里想特别说下entity、dto、vo三者为什么要分开。很多初学者喜欢直接用entity去接前端传来的参数也直接用entity去返回数据。但entity是跟数据库表一一对应的直接用会带来接口数据暴露过于底层、表中多余的字段一并返回等问题。我在项目里把前端入参封装成dto把给前端的返回数据封装成vo虽然多写了一点类但接口的语义清晰了后续字段调整也互不影响。Service层我习惯把事务边界控制在这里。比如创建订单时要同时往orders表和order_item表写数据还要扣减宠物库存、清空对应的购物车项这是个典型的多表操作场景必须在方法上加上Transactional注解。如果中途任何一步抛异常整个事务直接回滚不会出现订单建了但订单项没写入这种脏数据问题。3.2 统一返回结果与全局异常处理前端调用后端接口时后端不能一会儿返回这种格式一会儿返回另一种格式必须有一套统一的数据结构。我用的是最经典的code、msg、data三段式public class ResultT { private Integer code; private String msg; private T data; // 成功的返回 public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMsg(操作成功); result.setData(data); return result; } // 失败的返回 public static T ResultT error(String msg) { ResultT result new Result(); result.setCode(500); result.setMsg(msg); return result; } }统一返回结构配合全局异常处理器整个项目的错误处理就规范了。我自定义了一个业务异常类BizException在Service层处理业务逻辑时遇到参数校验不通过、库存不足、订单状态不允许操作等情况直接抛出BizException由全局异常处理器统一捕获并转换成Result返回。这样Controller层就不需要到处写try-catch代码瞬间干净很多。3.3 MyBatis在项目里的实践细节MyBatis这块是项目的核心数据处理层项目中不是简单地写CRUD而是用到了不少值得记录的实践。项目启动时我开启了MyBatis的驼峰映射配置。因为数据库字段是下划线风格的category_id而Java属性是驼峰风格的categoryId加上map-underscore-to-camel-casetrue之后MyBatis会自动完成映射不需要每个字段都手写resultMap。动态SQL是另一个重点。宠物列表页的筛选项是可选的用户可能只选分类可能只搜关键词也可能啥都不选。在Mapper的XML里用 和 标签组合就能实现一个方法应对所有查询条件select idselectPetList resultTypecom.petmall.entity.Pet SELECT * FROM pet where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND pet_name LIKE CONCAT(%, #{keyword}, %) /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if /where ORDER BY create_time DESC /select注意一下MyBatis在XML中处理小于号和大于号要用和转义不然XML解析会直接报错第一次写动态SQL时经常在这里翻车。MyBatis的缓存机制项目中用到了基础的二级缓存。对于宠物分类这种几乎不变的数据我在Mapper上开启了二级缓存减少对数据库的重复查询。但要注意二级缓存默认是Mapper级别的如果多表关联查询时表数据更新了其他Mapper的缓存可能没有同步失效所以缓存只用在分类表这种很少变更且无关联的查询上。订单、用户这种频繁更新的数据坚决不开缓存防止读到脏数据。批量操作这块也实践了一次。后台管理中管理员批量下架宠物时如果一条条执行UPDATE性能太差。我用MyBatis的foreach标签实现了批量更新update idbatchUpdateStatus UPDATE pet SET status #{status} WHERE id IN foreach collectionids itemid open( separator, close) #{id} /foreach /update这种写法在数据量不大时性能提升很明显而且SQL语句清晰易懂。3.4 Token鉴权与拦截器实现前后端分离后Session这套方案就不太好用了因为接口请求可能来自不同域名SessionId跨域保存和同步比较麻烦。项目里用的是JWT Token方案。用户登录成功后后端通过JWT生成一个带过期时间的Token返回给前端前端后续的每个请求都在请求头里带上这个Token后端通过拦截器统一校验。拦截器在项目里承担了登录态校验的职责。我在WebConfig里注册了拦截器并配置了排除路径。像用户登录、注册、宠物列表、宠物详情这些接口不需要登录就能访问而购物车、订单、个人中心相关的接口必须登录才能调用。拦截器里先从请求头里取出Token解析失败直接返回401让前端跳转到登录页解析成功就把用户信息放进请求上下文方便后续接口取用。这里有一个比较关键的细节拦截器放行接口的配置必须和前端路由的访问策略一致。刚开始我把宠物详情接口排除在拦截器之外后来发现用户未登录状态下也能访问购物车接口当时排查了半天才发现是Shiro配置里漏了放行规则走了不少弯路。4. 前端Vue项目搭建与接口联调4.1 Vue环境安装与项目初始化前端环境这块很多新手卡在Node.js和Vue CLI的安装上。我用的Node版本是16.x搭配Vue CLI 4.x。安装完Node.js后用npm install -g vue/cli全局安装脚手架然后通过vue create pet-mall-front选择Vue 2的预设模板来创建项目。npm的镜像源如果下载慢可以切换到国内镜像源否则装依赖时等到怀疑人生。项目里我还引入了Element UI作为UI组件库。做管理后台这类界面Element UI的表格、表单、弹窗组件非常好用能省下大量写样式的时间。Axios作为HTTP请求库负责和后端接口通信。这三个是前端项目的核心依赖另外再加上Vue Router和Vuex就齐活了。Vuex里我用它来管理用户的登录状态。用户登录成功后把用户基本信息和Token存到Vuex里同时持久化到localStorage这样用户刷新页面后登录状态还在。Vue Router的路由守卫里再检查一下有没有Token没有的话就拦下来跳到登录页有的话放行。4.2 Axios请求封装与Token处理Axios的封装是前端项目里最重要的环节之一。我在项目的utils目录下专门写了一个request.js文件统一配置Axios的baseURL、请求超时时间、请求拦截器和响应拦截器。请求拦截器里做了一件事从localStorage取出Token加到请求头的Authorization字段上。service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }, error { return Promise.reject(error) })响应拦截器的核心任务是处理后端返回的统一结构以及处理接口鉴权失败的情况。后端返回的code如果在200就直接把data部分返回给业务层code等于401说明Token过期或未登录这时要清空本地登录状态然后跳转到登录页其他code就把msg里的错误信息通过Element UI的Message组件弹出来。这个封装做完之后页面里调接口的代码非常干净。比如获取宠物列表只需要调用api/pet.js里封装好的方法不用每个请求都去写一遍Token的逻辑。4.3 页面设计与组件拆分前端页面的组织按照业务模块来拆。前台用户端的主要页面包括首页宠物推荐和轮播图、宠物列表页分类筛选、关键词搜索、分页、宠物详情页、购物车页面、订单结算页、订单列表页、个人中心页。后台管理端则包括登录页面、宠物管理列表、新增、编辑、订单管理、用户管理。组件的拆分逻辑是“能复用的绝不多写一遍”。宠物卡片在首页和宠物列表页都要用到就抽成一个单独的PetCard组件分页组件在列表页、订单页都要使用也抽出来。这样后面改了样式只需要在一个地方改全局生效。路由层面前台和后台分别用不同的路由布局前台是带顶部导航栏和底部栏的布局后台是带侧边栏的布局。通过Vue Router的嵌套路由实现这样每个页面只需要关注自己的内容区域整体的代码复用性会高很多。4.4 前后端联调的核心注意事项前后端联调阶段最大的问题是跨域。前端开发时跑在8080端口后端跑在8081端口浏览器会直接拦截跨域请求。我的处理方式是在后端SpringBoot里配置全局跨域支持通过CorsFilter允许前端地址访问。这样开发环境下前端就能直接请求后端接口。发布到线上之后我换了一种更稳妥的方案Nginx把前端静态资源服务和后端接口反向代理放在同一个端口下通过不同的路径前缀区分。比如/api开头的请求转发到后端的SpringBoot服务其他请求返回前端静态资源。这样浏览器看到的始终是同源的请求彻底避开了跨域问题。这个方案是项目上线前必须处理的环节推荐大家都采用这种方式替代前端的开发代理。联调时还有一个必查项前后端对日期时间格式的处理要一致。Java端返回的LocalDateTime默认格式是带T的ISO格式前端如果想要“2024-04-19 10:30:00”这种格式要么后端在JSON配置里指定全局日期格式要么前端拿到数据后自己格式化。我在SpringBoot配置文件里加了一个统一的Jackson日期格式化配置这样前端拿到的就是常规的日期时间字符串减少很多不必要的麻烦。5. 部署上线与常见问题排查5.1 前后端的打包与环境准备部署是这个项目的最后一公里多少项目卡在“本地跑得好好的一上线就废了”这一步。前端打包之前最关键的一步是修改接口地址。开发环境里请求的是http://localhost:8081打包上线后要改成线上域名。我的做法是通过环境变量来区分在项目根目录建.env.development和.env.production两个文件分别配置开发环境和生产环境的接口地址打包时用对应的模式去构建。后端打包时要留意配置文件的差异。本地连接的是开发库线上要连线上数据库。SpringBoot提供了多环境配置机制application.yml放公共配置application-dev.yml放开发环境配置application-prod.yml放生产环境配置启动时通过spring.profiles.active指定激活哪套配置。这样环境切换只需要一个启动参数非常省心。MySQL数据库这边需要先建好库、执行建表SQL然后配置好账号权限。建表SQL我单独整理成了一个sql文件同时放了一些测试数据方便部署后马上能看到页面效果。前后端都准备好之后完整的部署流程是这样的前端执行npm run build生成dist目录把dist目录上传到服务器的指定目录后端用mvn package打成jar包上传到服务器在服务器上配置好Nginx将前端目录指到dist将/api开头的请求反向代理到后端端口最后启动jar包访问服务器域名就能看到完整的商城网站。5.2 常见问题排查速查表这个项目从开发到部署我自己整理了一份问题排查速查表每一类问题都是实际踩过坑之后总结出来的。问题现象可能原因排查思路与解决方案前端请求接口报跨域错误后端未配置跨域或Nginx代理未生效先看浏览器控制台的具体报错开发环境检查后端CorsFilter配置线上环境检查Nginx的proxy_pass路径是否正确登录后每次刷新页面就退出登录Token没有存到localStorage检查登录成功后是否执行了localStorage.setItem操作Vuex的state初始化时也要从localStorage里读一次MyBatis执行报错信息不明确日志级别未打印SQL在application.yml里配置mybatis的日志级别为debug查看控制台打印的SQL语句和参数订单创建成功但订单项没写入事务未生效检查Service方法是否是publicTransactional注解是否加在方法上SpringBoot启动类是否加了EnableTransactionManagement宠物列表页搜索条件无效动态SQL条件未拼接检查Mapper XML里 标签的test条件是否和前端传入的参数名一致用日志打印最终SQL来定位部署后前端页面能打开但接口404Nginx的proxy_pass路径配错检查Nginx反向代理的location路径和后端context-path是否匹配特别注意/api路径后面要不要加斜杠前端打包后页面布局异常静态资源路径配置不对在vue.config.js里把publicPath改为相对路径 ./接口返回数据带反斜杠时区不一致Jackson日期格式未配置在application.yml配置spring.jackson.date-format和time-zone5.3 部署过程中的几个重要坑点部署阶段有几个坑值得反复提醒。第一个是MySQL连接的时区问题如果连接串没有设置serverTimezone启动后端时即使能连上数据库返回的时间数据可能出现时区偏移。我在这里踩过一个雷折腾了半小时最后发现是时区参数没配置对加上serverTimezoneAsia/Shanghai以后问题就消失了。第二个坑是Nginx代理路径的斜杠问题。proxy_pass后面如果没有以斜杠结尾和以斜杠结尾的行为不一样。比如代理到http://127.0.0.1:8081/时会把请求路径中location匹配的部分替换掉不加斜杠则保留完整路径。这个细节不搞清楚接口很容易全部404。第三个坑是前端环境变量的读取问题。Vue CLI项目里面环境变量必须以VUE_APP_开头否则打包时不会注入到代码里。项目第一次上线时我按习惯命名为API_BASE_URL结果怎么都读不到查文档才发现前缀要求改成VUE_APP_API_BASE_URL后立刻正常。第四个坑是服务器防火墙和云安全组。如果买的是云服务器MySQL和SpringBoot的端口不仅要通过操作系统的防火墙还要在云控制台的安全组里放行。第一次部署时所有的配置都正确但外部就是访问不到检查了一圈才发现是安全组没有放行8081端口。5.4 日常开发中的效率工具顺带分享几个开发中提升效率的工具配置。后端开发时我配置了MyBatis的SQL日志打印插件这样每次查询都能在控制台看到完整的SQL语句和参数值排查问题时比靠猜高效得多。SpringBoot开发时开启了devtools热部署改完代码保存后自动重启省去手动重启的时间。前端开发时Vue CLI的热更新是默认开启的改完代码页面自动刷新这个体验比传统的页面刷新流畅很多。我还装了ESLint和Prettier代码格式自动规范团队协作时能省很多沟通成本。另外后端接口调试工具我用的Postman。接口开发完成后先在Postman里确认返回结构和数据都正常再交给前端联调这样能减少前后端来回扯皮的情况。Postman还有个实用的功能可以导出接口文档方便团队协作使用。6. 这个项目后续可以怎么扩展做完这套基础版本之后我持续在思考这个项目往深了走还能做什么。最值得做的是接入支付功能。目前订单模块是模拟支付真正上线的话可以对接主流的第三方支付平台对接完成后订单状态流转就会形成更真实的闭环。商品模块可以考虑做宠物图片的批量上传和压缩处理。目前项目里图片是存了URL地址如果做成真正的商用系统需要一个图片服务来处理用户上传的图片压缩、缩略图、CDN加速这些都要考虑进去。前端也可以考虑做更丰富的交互体验比如宠物列表页的瀑布流布局、详情页的图片放大预览、搜索关键字的实时联想这些功能都能显著提升用户体验。前端方面移动端适配是另一个方向。现在很多用户习惯用手机逛商城可以考虑把前台部分改造成响应式布局或者直接基于uni-app做一套小程序版本复用现有后端接口。后端则可以考虑引入Redis做热点数据缓存比如首页的宠物推荐列表和宠物分类信息把高频查询的数据从MySQL搬到缓存里在性能上能有明显提升。做项目的过程中有一个很深的体会不要只停留在把功能“写完”多想想每个模块还能怎么改进这样进步才会更快。就好比同一个宠物列表接口第一次实现时只是简单地返回全部数据后来加了分页加了搜索又加了缓存每加一层都是对业务和技术的更深理解。这种打磨的过程才是做项目最大的价值所在。如果你准备拿这个项目当简历项目面试时一定要把几个核心设计思路吃透为什么用前后端分离、购物车到订单的数据流转逻辑是什么、Token鉴权的流程是怎么设计的、数据库表之间的关联关系如何。把这些讲清楚面试官基本都会认可这是真实实践过的项目。我个人在这套系统上的体会是一个完整的全栈项目真正的难点不在某个单一技术点而在技术点之间的衔接。前端要理解后端的接口设计后端要理解前端的传参方式部署时还要懂点Nginx和Linux操作。把这些串联起来的能力恰恰是技术成长中最值钱的部分。希望这份实战记录对正在做类似项目的你有帮助。