做毕业设计选电商系统的人很多但真正能把“服装购物商城”做出完整度、能顺利通过答辩的靠的不是堆功能而是对整个前后端分离架构的理解。我用SpringBoot和Vue搭过一套基于前后端分离的在线服饰销售平台从选题、表设计、接口开发到前端联调、打包部署全程走了一遍这篇就把我在这个过程中踩过的坑、想明白的道理、可以复用的代码思路一次性说出来。不管你是准备做类似题目还是手里已经有项目不知道从哪下手这篇都值得你花十分钟看完。1. 项目整体设计与思路拆解1.1 为什么选“服装购物商城”作为毕业设计题目计算机毕业设计选题有个普遍规律太简单显得工作量不够太复杂容易烂尾。“服装购物商城”这个题目刚好卡在了一个很舒服的位置——它有电商系统的通用性做的是商品、购物车、订单、用户这套核心链路同时服装品类又有自己的特点比如颜色、尺码这种多规格属性比单纯做个图书或数码商城多了一层设计难度。这个度把握好工作量看着饱满实际做起来也不会失控。再从展示角度说服装商城的视觉效果天然比后台管理系统好。SpringBoot和Vue这套组合前端页面有发挥空间轮播图、商品卡片、购物车动画、订单状态标签这些都能让答辩PPT和演示视频好看很多。面试聊项目时也容易讲清楚业务逻辑不至于说着说着自己都绕晕。还有一个很现实的原因服装电商系统相关的参考代码、文档、开源项目非常多遇到搞不定的细节能找到人讨论不至于一个人闷头卡死。对大多数同学来说这个题目的“容错率”是比较高的。1.2 技术选型SpringBoot和Vue为什么是绝配技术选型看着是顺手的事其实决定了后面三个月是舒服还是遭罪。后端选SpringBoot核心理由是“约定大于配置”。它内置了Tomcat一套SpringMVC就够处理接口请求配合Spring Data JPA或者MyBatis-Plus操作数据库不用写一堆XML配置。对比传统的SSM框架SpringBoot省掉的不只是配置文件更是调试和部署时的心理负担。前端选Vue因为它对新手最友好。数据双向绑定让表单处理、购物车数量加减这类交互变得很直观Vue Router管页面跳转Vuex或Pinia管全局状态加上Element UI之类的组件库一个商品列表页面半天就能搭得有模有样。和React相比Vue的中文资料更全遇到问题搜一下就能找到解法。前端和后端通过HTTP接口通信这就是前后端分离的核心。前端专注渲染和交互后端专注业务逻辑和数据存储两个项目可以并行开发联调时只要保证接口格式对齐就行。这种模式不只是毕业设计的主流也是目前中小型公司做业务系统的标准姿势做完这套你对企业开发流程会有一个很具体的认识。1.3 整体功能架构和模块划分我的项目把功能分成两个端用户端前台商城用户注册登录、浏览首页、商品分类筛选、商品详情查看、加入购物车、提交订单、模拟支付、查看订单状态、个人中心管理。管理端后台系统管理员登录、商品管理上下架、库存维护、分类管理、订单管理发货、退款处理、用户管理、基础数据统计。模块划分遵循的原则是“低耦合高内聚”。商品模块管商品和分类订单模块管订单和订单项用户模块管登录鉴权和收货地址每个模块的接口边界清晰不互相兜底。这样做的好处是开发时能一块一块独立完成、独立测试答辩被问“某个功能是怎么实现的”时也能快速定位到对应代码不慌。2. 核心功能模块解析与数据库设计2.1 用户端四个核心流程注册登录流程。注册时前端做一次格式校验手机号位数、密码长度真正重要的是后端校验。第一次做很容易忽略“用户名是否已存在”这个判断导致重复注册。我当时在Service层里先根据用户名查一次库存在就抛异常由全局异常处理器统一返回提示信息前端弹个消息提示就完事。登录用的是JWT令牌用户登录成功后返回一串Token前端存在localStorage里之后每次请求在请求头加上Authorization: Bearer token后端通过拦截器解析出用户信息。商品浏览流程。首页展示轮播图、新品推荐、热卖榜单这些接口都做了简单的数据缓存。最开始我每次请求都直接查数据库后来发现刷新一下页面就要等半秒多体验很糟。加了Redis做缓存后热销商品和推荐位的数据直接走缓存快了很多。分类筛选参数包括大类上衣、裤装、裙装、子类T恤、衬衫、牛仔裤、价格区间、尺码和颜色。这里我一开始踩了个坑把所有筛选参数拼成一个大SQL结果索引失效查询很慢。后来改成了组合查询并根据查询条件动态构建SQL性能从两秒降到了几百毫秒。购物车流程。购物车的核心不是一个简单的“加入就完事”而是要处理已有商品数量累加、规格变更、库存校验。我的做法是后端先查出购物车中是否已存在同款商品商品ID规格ID做联合判断存在则数量累加否则新增一条记录。结算时对购物车内的每一项做库存二次校验防止下单时才发现某个商品已经没货了。订单流程。提交订单是前端所有操作里最需要小心的一步。我当时的做法是前端把收货地址ID、购物车选中的商品项列表一并提交给后端后端在自己那边重新计算价格并生成订单而不是直接信任前端传过来的金额。这个点即便答辩时不展开讲自己心里也要清楚这是电商系统最基本的“金额安全”意识。订单状态我设计了五种待付款、待发货、待收货、已完成、已取消。前端通过订单状态码展示对应的操作按钮和进度条样式后端负责状态流转的控制比如只有待付款状态才能点取消。2.2 管理端核心功能管理端用同一个SpringBoot项目提供接口前端独立一套页面。登录鉴权是后台最常见的场景管理员登录后后端接口用拦截器判断请求路径是否在放行名单内不在名单内的请求都会校验Token防止未登录访问数据接口。商品管理这边我封装了独立的文件上传接口管理员在商品编辑表单里选择图片后上传到服务器本地磁盘数据库里存的是访问路径。这个方案单机演示完全够用如果后来要部署到云服务器再考虑接对象存储也不迟。订单管理是后台最忙的模块。列表默认按创建时间倒序排列状态筛选支持多条件联动还可以针对单笔订单做发货操作发货时填写物流单号。测试时我在一个账号下连续下好几单通过不同的状态看前台展示是否同步更新这样一套流程跑下来基本能把核心链路验证完。2.3 数据库设计核心表的字段与关系数据库设计直接决定开发时的痛苦程度。我最终用了6张核心表用户表、分类表、商品表、商品规格表、购物车表、订单表、订单项表以及一张用来存轮播图和公告的附加表。商品表和商品规格表是一对多关系。一件衣服可以有好几个颜色、好几个尺码我把价格和库存都放在规格表里商品表只保留标题、主图、描述、销量这些公共字段。这样商品详情页展示SKU信息时只要根据商品ID查规格表就能拿到全部选项和对应价格。订单表和订单项表是一对多关系。订单表存收货人、总金额、状态等汇总信息订单项表存每个商品的快照信息包括商品名称、规格描述、单价、数量和图片。为什么存快照而不关联商品表因为商品下架或改价后历史订单显示的信息不能跟着变快照方案保证订单内容是“下单那一刻”的真实状态。这个设计在答辩时非常能体现你对业务的理解因为很多人做的订单表就是简单一张表根本没考虑历史快照的问题。3. 实操过程与核心环节实现3.1 后端接口设计与JWT登录鉴权后端接口设计遵循RESTful风格资源名用复数名词比如/api/products、/api/orders。用HTTP方法表达操作类型GET查询、POST新增、PUT修改、DELETE删除。这样接口风格统一也方便前端理解和对接。JWT登录是这部分的重点我写一下关键思路// 登录成功后生成Token String token Jwts.builder() .setSubject(userId.toString()) .claim(username, username) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 3600_000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();用户每次请求时携带Token。拦截器获取Token后解析把用户ID放到请求上下文里后面的业务代码随时能取到当前登录用户的身份。比如修改个人信息前先判断用户ID是否匹配防止操作别人的数据。JWT的好处是服务端不用存储会话状态非常适合前后端分离的分布式场景。它的缺点是Token一旦签发就不能主动作废所以在用户注销或修改密码时前端直接删除本地Token即可把安全问题控制在可接受范围内。3.2 前端Vue页面结构与核心组件实现前端页面用Vue Router管理路由页面组件分包存放。views目录下按登录注册、首页、商品列表、商品详情、购物车、订单、个人中心来组织后台页面放在views/admin里。商品列表页是重点组件用Element UI的卡片布局展示商品分页组件绑定数据变化点击分页时重新向后端发起请求。加了一个价格区间的筛选条通过v-model绑定输入值点击查询后向列表接口发送筛选参数。购物车页面要处理的数据比较杂每一行的勾选状态、数量、小计底部实时汇总选中商品的总价。我用了Vue的计算属性computed而不是在方法里手动算只要勾选状态或数量一变化总价自动更新代码非常干净。订单结算页面用Steps步骤条让用户看出当前处于哪个阶段地址选择用对话框弹出一个地址列表让用户选择默认的地址再通过确认按钮提交订单。这里要注意的是地址列表是异步加载的我在组件挂载时从后端拉取一次用户新增地址后再刷新一次保证表单里拿到的地址数据是最新的。3.3 前后端联调与接口对接前后端分离的项目最容易出问题的不是在单独调试时而是双方约好的接口格式对不上导致的反复联调。我的实际做法是首先在项目初期用接口文档工具把每个接口的路径、请求参数、返回结构定死开发时后端自己用Postman先跑通前端在Vue项目里给接口请求封装一个统一的axios实例统一处理请求头、超时时间和错误拦截。前端拿到返回结果时data统一包在response.data.data这层这样不管后端返回什么数据结构前端解析方式都是固定的。联调过程中最常遇见的几个问题我记在下面后端返回的日期格式是时间戳前端显示不了就统一在实体类上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)或者前端在渲染前格式化。后端接口要求接收的字段名是goodsId前端传的是productId联调时怎么都拿不到数据最后逐个字段核对才找到这种低级错误一旦发生就很浪费时间。文件上传接口返回的地址是服务器相对路径前端拼接时要确认是否有域名和上下文路径拼接错了页面就显示裂图。建议从一开始就使用Swagger或者Knife4j自动生成接口文档。接口文档能让前后端并行开发减少大量不必要的沟通成本。3.4 项目打包部署与答辩准备开发完成后前后端需要分别打包。后端SpringBoot项目打包成可执行Jar包我用的是标准的Maven命令mvn clean package -DskipTests java -jar target/shop-api.jar前端Vue项目执行npm run build构建完成后dist目录里的静态文件可以放到Nginx的静态目录下。为了让刷新页面时不出现404需要在Nginx配置里把路由请求都重定向到index.html。location / { try_files $uri $uri/ /index.html; }实际答辩时演示环境可以全部在本地跑后端Idea里启动前端npm run dev启动浏览器直接打开。为了保险我又把Vue打包后的文件放到了SpringBoot的static目录里让后端口径统一能访问到前端页面这样即使不单独启动前端也能够正常演示不会出现断电断网导致演示失败的情况。答辩PPT里我放了系统架构图、功能模块图、数据库ER图、几个核心页面的截图再加上一段事先录好的操作演示视频。这样就算现场网络出了问题也能靠视频走完整个流程。4. 常见问题与排查技巧实录4.1 跨域请求配置问题前后端分离后前端跑在localhost:8080后端跑在localhost:9090浏览器默认会拦截跨域请求。报错信息一般是“CORS policy”字样非常显眼。解决方法是在SpringBoot里配置全局跨域支持Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意一个细节如果使用了自定义拦截器预检请求OPTIONS要先放行否则前端请求会被拦截器拦掉。当时我排查这个问题花了一个多小时最后在拦截器里加了一行对OPTIONS请求直接放行的判断瞬间就好了。4.2 登录状态刷新后丢失前端登录后把Token存到了localStorage页面一刷新Vuex里的用户信息就空了。原因是Vuex的数据是存内存里的刷新就没了。解决办法是在页面加载时重新从localStorage读取用户信息并初始化Vuex状态。我封装了一个getCurrentUser()的接口在应用入口判断本地是否存在Token存在就调用该接口拉取用户信息再更新Vuex里的状态。这样刷新页面后登录状态依然保持整个体验连续性很强。4.3 图片上传后不能正常访问本地开发时图片上传到了后端项目的upload目录前端访问时直接用localhost:9090/upload/xxx.jpg加了一层代理转发问题就出现了。Nginx或者开发环境代理没有把图片访问路径转发到后端端口所以显示裂图。解决办法有两个方向一是前端图片地址直接写全路径缺点是耦合度高二是配置代理把/upload这个路径转发到后端我这里因为本地是直接用Vite开发所以在vite.config.js里加了代理配置把上传相关的请求转发到9090端口问题就解决了。如果是打包部署在同一个端口下则由于后端静态资源映射默认生效一般不会出现这个情况。4.4 结算时的库存并发问题同一个商品同时被两个人下单可能会出现超卖。我在库存扣减时使用了乐观锁核心SQL变成带条件更新UPDATE product_sku SET stock stock - 1 WHERE sku_id ? AND stock 0;受影响行数为0就说明库存不足或已被抢空此时抛出业务异常并回滚事务。这个处理方式非常简单有效在面试场景中说出来会显得你思考过数据一致性问题。4.5 订单状态显示混乱订单状态数字和前端展示名称对不上原因基本是前后端状态枚举没有对齐。我后来将状态定义写在一个共享接口文档里前后端都从同一个状态常量表取用。前端用状态码映射到对应的文案和标签颜色后端在返回时额外带一个状态描述字符串。这样即使以后状态增加前端也不需要大量改动。5. 时间规划与个人实操体会5.1 项目开发的时间怎么分配完整走完这套项目我的时间分配供参考需求整理和功能列表梳理3到5天数据库设计和表格关系整理2到3天后端基础框架搭建和用户、商品模块接口7到10天购物车、订单模块接口开发5到7天前端页面开发和组件设计10到14天前后端联调和问题修复5到7天部署、文档撰写和答辩准备5到7天总周期在一个半月到两个月之间每天保证三个小时以上的有效编码时间。如果时间紧张前端可以优先做核心链路砍掉优惠券、积分这类非核心功能但商品、购物车、订单这三条主流程一定要完整。5.2 开发过程中的一些经验教训调试接口时先看清后端日志。SpringBoot的报错堆栈信息非常详细很多时候问题一眼就能定位但新手容易只看前端控制台的方向后端明明写了明确异常却被忽略。把前后端分开排查先确认接口返回的状态码和响应体再去翻业务代码。关于代码命名实体类、字段名的命名风格前后端保持一致。当时前端习惯用驼峰后端数据库字段用的是下划线。SpringBoot默认配置能帮我们自动做驼峰和下划线的映射但如果你用了MyBatis并关闭了驼峰映射就得手动写映射关系很容易漏掉字段导致返回的数据全是null。第一次踩到这个问题时我在每个字段上写TableField后面直接调整为开启全局驼峰映射少写了很多重复代码。备份管理好数据库。开发中我改了好几次表结构每次都忘记导出SQL备份结果有一次改字段类型把已有数据搞坏了折腾了半天才恢复数据源。建议每完成一个小模块就导出一份完整的SQL脚本提交到Git里作为存档。用Git管理代码这个习惯值得尽早养成。每天提交一次提交信息写清楚当天做了什么回滚代码、对比差异都会变得非常轻松。答辩前如果改出问题不至于因为找不到之前的可用版本而紧张。6. 这套项目还能怎么扩展横向扩展有几个方向接入支付宝沙箱支付或微信支付模拟集成定时任务做订单超时自动关闭利用Elasticsearch做商品全文搜索引入RabbitMQ做下单后的异步通知和库存扣减。纵向扩展则可以增加用户积分体系、优惠券系统、秒杀活动等。这些扩展点不用全做挑一个做成“亮点功能”就足够在答辩或面试时讲了。我当时挑了支付宝沙箱支付在模拟环境下走通了从提交订单到跳转支付、支付成功回调修改订单状态的完整链路。光是这个点答辩时老师追问了很多细节都对答如流效果比我预想的要好。前端的扩展相对容易比如把首页改成支持懒加载图片商品列表加入防抖搜索购物车做滑动删除的手势交互。但实操上不要贪多核心功能稳定、逻辑严谨、有思考深度才是最重要的。最后说一句实际的体会毕设项目没有你想象中那么看重“功能多”它更看重你对每一块功能的理解程度。面试官或答辩老师问一句“你订单状态是怎么流转的”你要是能一口气从提交订单到支付回调、发货、确认收货、超时取消讲清楚这个项目就已经是你的加分项了。SpringBoot和Vue这套组合课外的坑是有限的踩过一遍、记录下来这些经验就都是你的了。