毕业设计季又来了，每年这个时候都有大量同学在"电商系统"选题上反复横跳。如果你正在做一个基于SpringBoot的体育购物商城，或者还没定题、正在评估这个方向，那这篇分享值得你坐下来慢慢看。

我会把整个"体育购物商城"从设计思路、技术选型、核心模块拆解，到实际编码中的关键细节、调试部署、文档编写，全部过一遍。我假设你用的是目前最主流的组合：后端SpringBoot + MyBatis（或MyBatis-Plus） + MySQL，前端Vue + Element UI，前后端完全分离，接口以JSON交互。这套组合在近几年的相关项目中几乎成了标配，因为它足够稳、资料多、踩坑成本低，而且演示效果好看。

这篇文章不太一样的地方在于：我会把重点放在那些你写代码时容易漏掉、答辩时容易被问住、文档里又不会明说的点上。比如为什么订单状态要设计成那样、购物车改库存该在哪里做、JWT过期了前端怎么处理、支付宝沙箱到底怎么跳转。这些才是让一个项目从"能跑"变成"能过"的关键。

1. 项目整体设计与技术选型思路

1.1 项目定位与核心需求解析

先搞清楚一件事：这个项目首要目标是"完整可用"，其次才是"技术亮点"。一个体育购物商城的核心用户无非两种：普通消费者和管理员。消费者的完整链路是：注册登录 → 浏览商品 → 搜索筛选 → 加入购物车 → 提交订单 → 模拟支付 → 查看订单状态。管理员的完整链路是：登录后台 → 管理商品分类和上下架 → 处理订单（发货） → 管理用户 → 查看统计报表。

把这两条链路走通，项目的主体功能就闭环了。要注意的是，很多同学在起步阶段喜欢把功能表列得特别大，什么积分系统、秒杀、优惠券、社区评论都往上堆，结果写到一半写不动了。我的建议是：主干优先，分支后缀。第一版先把商品、购物车、订单、支付、用户管理这五件事做扎实，这就是一个能打70分的项目了。后期时间富余，再加评论和优惠券。

体育商城的特殊点在哪里？在于商品维度和属性。卖球鞋、球拍、运动服和卖手机、卖书不一样。运动商品天然有品牌、尺码、颜色、适用运动类型这些维度。比如一双篮球鞋，你至少要区分"42码/黑色/李宁"和"42码/白色/李宁"是不是同一个商品。这就是标准的SKU（库存量单位）问题。做表设计时必须考虑商品多规格，否则答辩时导师一句"你这双鞋的黑色42码缺货怎么处理？"就能把你问住。

1.2 为什么选择前后端分离架构

这个项目要求前后端分离，这个选择在实际开发里非常主流，但在课程设计里很多同学不理解原因，答辩时容易答偏。前后端分离的本质是：前端只做界面渲染和用户交互，后端只做业务逻辑和数据处理，两者通过HTTP接口通信，各管各的，互不侵入。

这么设计的直接好处有三个。第一，前端和后端可以并行开发互不等待。你做后端的接口定义好DTO（数据传输对象），前端同学就能拿着Mock数据先写页面。第二，部署灵活。前端可以用Nginx托管静态文件，后端独立启动在8080端口，任何一端出问题都不影响另一端重新部署。第三，后期扩展方便。如果你以后想做一个移动端商城，后端接口完全可以复用，只需要新写一个前端应用就行。

代价也很明显：跨域问题、Token管理、接口文档约定，这些都是前后端分离带来的新麻烦。后面我会专门讲这些坑怎么填。

1.3 技术栈选型的底层逻辑

• SpringBoot：不用多说，它的自动配置和起步依赖让项目搭建成本极低。一个商城项目的核心依赖就那几个：spring-boot-starter-web、spring-boot-starter-validation、spring-boot-starter-security（或者不用Security只靠JWT拦截器）、MyBatis-Plus、MySQL驱动、FastJSON或Jackson、Lombok。
• MyBatis-Plus：强烈建议用，尤其时间紧的情况下。它的内置BaseMapper能省掉大量CRUD的SQL编写，分页插件一集成，分页查询几行代码搞定。对于课程设计级别项目，手写XML其实没必要。
• MySQL：这个没什么争议。商城涉及的关联查询无非就是用户、商品、订单这几张主表加几张关系表，MySQL完全够用。表结构设计好了，性能不是问题。
• Vue + Element UI：Vue 2 + Element UI的组合目前资料最多，组件最全，适合快速搭后台管理系统；如果导师要求新一点的技术栈，Vue 3 + Element Plus也行。区别主要在写法上，Composition API和Options API的差异，但组件用法几乎一样。
• Redis：严格说一个课程设计项目不引入Redis也能跑，因为SpringBoot自带的Session或者JWT的过期校验已经能满足需求。但如果你想让项目有亮点，我建议把Redis加上，至少用来做验证码缓存和购物车临时数据缓存。这是非常容易讲出彩的设计。我下面的内容会默认Redis作为验证码与部分热点数据缓存，如果没有Redis环境，用ConcurrentHashMap暂存验证码也能凑合过，但答辩会吃亏。

这里要特别说一句：技术选型不要贪多。每个引入的中间件都要能说清楚"它解决了什么问题"。如果你答不上来，那这个中间件就是减分项而不是加分项。

2. 后端核心设计与实现细节

2.1 数据库表设计思路与字段解析

商城系统表的设计有一条黄金原则：核心业务表之间不要直接做复杂的多对多关联，用中间表解耦。基于这个原则，我给出一个最小但完整的表结构集合（括号内是核心字段）：

• 用户表 user：id, username, password（MD5加盐或BCrypt加密）, nickname, avatar, phone, email, role（1表示普通用户，2表示管理员）, status（是否禁用）, create_time
• 商品分类表 category：id, name, parent_id（支持二级分类）, sort_order, status
• 商品表 product：id, category_id, name, subtitle（副标题）, main_image, detail_image（富文本详情）, price（默认价）, stock（总库存）, sales（销量）, status（上架/下架）, create_time
• 商品规格表 product_sku：id, product_id, specs（如"黑色 42码"）, price（规格单独定价）, stock（规格库存）, status
• 购物车表 cart：id, user_id, product_id, sku_id, quantity, checked（是否选中结算）, create_time
• 订单表 orders：id, order_no（业务单号）, user_id, total_amount, pay_amount（实付）, status（0待支付 1待发货 2待收货 3已完成 4已取消）, address_snapshot（收货地址快照）, create_time, pay_time, ship_time, finish_time
• 订单明细表 order_item：id, order_id, product_id, sku_id, product_name, product_image, price（成交价快照）, quantity
• 收货地址表 address：id, user_id, receiver_name, receiver_phone, province, city, district, detail, is_default
• 轮播图表 banner：id, image, url, sort_order, status

表设计的几个关键决策：

第一，订单表里为什么要存"快照"？因为商品的价格、名称可能会变。用户下单时买的是"当时的商品"，如果过了三天商家改了价格，你的订单里总不能也跟着变吧。所以order_item里的product_name、price必须是下单那一刻的数据，而不是通过外键去关联实时查询。这也是电商系统的通用做法，答辩时能讲出来绝对加分。

第二，购物车表为什么要冗余一个sku_id？因为用户加购的是具体某个规格，结算时你要拿着cart里的sku_id去锁定对应SKU的库存。

第三，逻辑外键优于物理外键。课程设计阶段尽量别在数据库层面加真实的外键约束（ON DELETE CASCADE那种），因为一旦涉及删除操作，外键的级联行为很容易把数据搞乱。用逻辑外键（只是有个字段存着关联表的ID）就够用，查询靠JOIN完成。

2.2 用户注册登录与JWT权限控制

用户这一块看起来简单，真正实现的时候有不少细节容易返工。

注册接口要注意三点。第一，密码不能明文存，前端把密码传过来之后后端要做BCrypt加密再入库。BCrypt的好处是每次加密的盐值随机，同样的密码两次加密结果都不同，防彩虹表。第二，用户名必须做唯一校验，但这个校验不光是查一次数据库就完事，而是在插入时捕获唯一索引冲突异常，双重保障。第三，邮箱/手机号做正则校验，后端必须校验一次，不能只靠前端。

登录接口的逻辑是：用户名+密码校验通过 → 生成Token返回给前端 → 前端把Token存到localStorage或Vuex/Pinia → 之后的每次请求在请求头里带"Authorization: Bearer token" → 后端每次通过拦截器解析Token并获取当前用户信息。

关于JWT（JSON Web Token）实现，我建议不要引入完整的Spring Security框架，因为它配置繁琐、概念多，对课程设计来说没有必要。用拦截器（HandlerInterceptor）加JWT工具类就足够了。核心流程是：

1. 用户登录成功后，用用户的id、用户名、角色等信息生成一个JWT字符串。
2. 后端写一个LoginInterceptor，重写preHandle方法，从请求头取Token，解析校验，放行或返回401。
3. 注册拦截器时排除登录、注册、商品浏览、搜索这些无需登录的接口路径。

有一点很容易被忽视：拦截器解析完Token后，怎么让后面的Controller拿到当前用户ID？做法是把它放入ThreadLocal或请求域中（比如request.setAttribute("userId", uid)）。在后面处理购物车、添加订单时，直接从请求里拿userId，不要指望前端传user_id给你。这是我的经验——前端传的user_id根本不可信，谁都能伪造。

验证码这一块，如果用Redis，流程就是：生成随机验证码 → 存到Redis，key是uuid，值是验证码，过期时间5分钟 → 把uuid和验证码图片一起返回给前端 → 登录时前端把uuid和用户输入的验证码一起提交 → 后端拿uuid去Redis取真实验证码比对。注意比对完成后必须删除这个key，防止验证码被反复使用。

2.3 商品模块的分页、搜索与多规格设计

商品列表页是用户访问最多的页面，也是评判一个商城是否"完整"的关键点。前台商品列表至少有四个入口：首页推荐、分类浏览、关键字搜索、热门排序（销量、价格、上新）。

服务端要做的是一个统一的分页查询接口：传入categoryId、keyword、sortType、pageNum、pageSize，返回当前页数据和总条数。MyBatis-Plus的分页插件集成很简单，写一个MybatisPlusInterceptor的配置类，把PaginationInnerInterceptor加进去就行。这里要提醒一点：分页插件查总条数默认是执行的count查询，大数据量下会有点慢，但课程设计不用担心，顶多几万条数据。

多规格是商品模块最重要的亮点。你要明白商品表和SKU表的关系：一件商品（如某款篮球鞋）可以有多个SKU（黑色42码、白色43码）。详情页展示时，用户选中一个SKU，前端通过skuId向后端请求该SKU的实时价格和库存。这里的关键是：列表页显示的商品价格应该是"最低价"。实现方式是在SQL里按商品ID分组求最低的SKU价格，或者查询时关联SKU表用MIN函数。等你展示商品列表时，每件商品显示价格都是"xxx起"，这既是电商常规操作，也是技术的细节表现。

商品搜索不要一上来就上Elasticsearch，那是给自己挖坑。MySQL的LIKE模糊查询，配合前端搜索框，完全够用。字段上加普通索引就足够了。

2.4 购物车与订单状态机的实现

购物车的核心操作无非：加商品、改数量、删除、选中/取消选中、结算前价格汇总。后端接口设计为：POST /cart/add、PUT /cart/update、DELETE /cart/delete、GET /cart/list。加购时注意幂等性：如果同一个用户往购物车里加了同一个SKU的商品，后端应该做数量累加而不是新增一条脏数据。另外，加购时库存校验在用户提交订单时做才是硬校验，加购时只需要提醒前端"当前库存充足还是紧张"，不必强锁库存。

订单模块是整个系统的核心，而订单核心中的核心是订单状态。我在前面给出了五态设计：待支付 → 待发货 → 待收货 → 已完成；任何时候都可以取消变成已取消。这是一个简化版的状态机，但已经能覆盖电商的主要场景。

下单流程的代码顺序是固定的，这个顺序是经过反复踩坑总结出来的：

1. 从购物车按勾选的商品生成订单主表和明细表数据。
2. 锁定库存：对每个SKU执行带条件的扣减SQL，例如UPDATE product_sku SET stock = stock - #{quantity} WHERE id = #{skuId} AND stock >= #{quantity}。执行后受影响行数为0说明库存不足，要立刻抛出业务异常并整体回滚。
3. 清空购物车中已下单的商品。
4. 因为扣减库存和生成订单在一个事务方法里，任何一步失败都会整体回滚，不会出现"订单没生成但库存扣了"或"订单生成了但库存没扣"的问题。

这里有个坏习惯必须改掉：不要用"先查库存再更新"的思路写并发扣库存。因为两个用户同时查到库存都是1，都执行扣减，如果不用带条件的UPDATE，就会出现超卖。上面那行带stock >= #{quantity}条件的UPDATE，在数据库层面保证了一次只有一个事务能扣成功，这就是乐观锁的思想。

2.5 支付模块的模拟实现方法与接口对接

支付模块是很多同学卡住的地方。我想先给个定心丸：课程设计项目的支付，99%是模拟支付，不需要真接微信支付或支付宝。理由很现实：真正的支付需要商户号、资质审核、签约，个人开发者拿不到，你也不想在答辩时因为支付没打通而尴尬。

模拟支付的实现方式有几种：

最简单的是"余额扣款"。用户表加一个balance字段，下单后跳转到一个支付确认页，点击"确认支付"调用后端接口扣减余额。这种方式逻辑简单、完全离线可调试，适合绝大多数场景。

如果你想做得好看一点，可以在支付页面放一个二维码图片（随便一张），旁边写"模拟支付，点击确认"。这样既能演示交互流程，又不会在答辩时被追问真实对接的细节。上一届有人用支付宝沙箱环境做过，效果确实好，但沙箱环境的配置、证书下载、回调验签这些环节非常磨人，一旦碰到版本兼容问题，就是好几个小时起步。我的建议是：除非你时间特别充裕，否则用模拟支付。

模拟支付的关键代码逻辑是：

1. 用户发起支付请求 → 后端校验订单存在且状态是待支付。
2. 更新订单支付状态为待发货，记录支付时间。
3. 增加对应商品的销量。

支付完成后要做的事情：更新订单状态、记录支付流水、通知前端跳转到订单详情页。这一串也要放到一个事务里。

2.6 管理员后台的统计与报表实现

后台的统计报表是项目视觉上最出效果的模块。一般做三块：商品总数、用户总数、订单总数，以及"近7日订单趋势"。趋势图用前端图表库ECharts展示，后端只需要提供一个接口返回最近7天的订单数量数组。

SQL写法是：SELECT DATE(create_time) as day, COUNT(*) as cnt FROM orders WHERE create_time >= #{startDate} GROUP BY DATE(create_time)。后端拿到这个列表后，在前端填到对应的坐标轴上。

后台管理的其他功能就是标准CRUD：商品管理（增删改查+上下架+多图上传），分类管理（两级分类维护），订单管理（列表+按状态筛选+发货操作），用户管理（列表+禁用/启用）。这里我说的CRUD并不是"生成器一键生成"那种简陋版本，而是每个功能都有业务判断的版本。比如下架商品时，如果该商品正在被某个待发货订单引用，应该提示"该商品存在未完成订单，建议谨慎下架"。这种业务细节填充进去，项目答辩时的技术含量立刻不一样。

3. 前端Vue设计与核心页面实现

3.1 Vue工程结构与请求封装

前端工程建议用Vue CLI或者Vite创建，名称随便起，比如sports-mall-web。目录结构按功能模块来分：api目录存放每个功能模块的接口请求函数，views目录存放页面组件，router目录配置路由，store目录管理全局状态（用户信息、购物车数量等）。

请求封装是前端必须做好的一件事。所有请求走统一的axios实例，这个实例要配置三件事：

• baseURL指向后端接口前缀，比如 http://localhost:8080/api，这样请求路径里就不用重复写。
• 请求拦截器自动从localStorage取Token，设置到请求头。
• 响应拦截器统一处理后端返回的HTTP状态码和业务码。重点来了：如果后端返回401（未登录或Token过期），前端要自动跳转到登录页并清掉本地用户信息，而不是在每个页面方法里手动写"错误处理"。这个拦截器写好了，你在写业务代码时会省非常多的力。

3.2 用户端核心页面实现要点

用户端页面主要有：首页、商品列表页、商品详情页、购物车页、订单确认页、支付页、个人中心。

首页相对简单，核心就是轮播图加"推荐商品"瀑布流。后端提供两个接口：/banner/list返回轮播图，/product/recommend返回推荐商品。推荐逻辑最简单可靠的是按销量降序取前N条。

商品列表页是性能大考。筛选条件（分类）、排序方式、分页参数要做到"响应式联动"。我给出的思路是：路由query里存筛选参数，点击筛选或排序调用接口重新加载，URL的变化通过watch监听后触发加载。这样一个页面能给多个入口复用（分类导航进来、搜索结果跳转进来）。

商品详情页要有三块关键内容：图片区（主图放大+缩略图切换）、SKU选择区（点选规格后价格变化）、购买区（加购物车或立即购买）。SKU选择在Vue里的实现逻辑是：点击一个规格项，查找对应的SKU记录，动态刷新展示价格和库存。如果某个规格组合不存在，按钮置灰。

购物车页的实时联动就要看前端基本功了。每个购物车条目能改数量、取消勾选，每个条目的选中状态变化都要重新计算"已选合计价格"。我的建议是：用computed计算属性，只要购物车数据一变，汇总自动更新。

下单流程里，订单确认页有两个细节值得说：收货地址列表的选择（默认地址高亮）和订单金额的明细展示。提交订单时注意传参结构：要把订单来自哪些购物车条目（cartIds）传过去，因为这个决定了下单后要清空哪些购物车记录。

3.3 后台管理端页面布局

后台管理端我建议直接用现成的Vue后台模板，比如vue-element-admin，或者手写一个简版：左边菜单栏，右边内容区，顶部导航栏。

关键页面就是商品新增/编辑页，这个页面是所有后台页面里最复杂的。因为表单字段多，而且涉及图片上传、富文本编辑、SKU动态增删。图片上传要先调后端的 /upload 接口拿到文件URL，再把URL赋值给表单字段。SKU动态增删是给一个表格，每行由"规格文本+价格+库存"组成，前端动态添加或删除行，提交时整个SKU数组传给后端。

订单管理页要能按订单状态筛选，核心动作是"发货"。点击发货弹窗填快递单号，确认后调用接口把订单状态从待发货变为待收货，并记录发货时间。这是后台和前台交互的关键场景，也是业务闭环的必要流程。

3.4 前后端联调与跨域问题解决

前后端分离开发最大的效率瓶颈就是联调。你本地前端跑在8081端口，后端跑在8080端口，大概率会遇到跨域问题（CORS）。解决办法有两个方案：

方案一，后端配置全局CORS。写一个WebMvcConfigurer的配置类，重写addCorsMappings方法，允许前端地址跨域。要注意allowedOriginPatterns不是allowedOrigins，因为allowCredentials设为true时，allowedOrigins不能是"*"。 方案二，前端配置开发环境代理。修改vue.config.js，把/api前缀的请求代理到http://localhost:8080。用代理的好处是浏览器始终访问的是同源的8081端口，完全无跨域概念。前端上线后，再让Nginx把/api反向代理到后端服务地址。我建议项目里用方案二，因为对接真实后端后，方案二几乎不需要再改。

接口对接时的另一个效率问题就是接口路径和参数约定。首先要做的是在你的接口文档里明确每一个字段的命名。我的经验做法是在前后端都建立相同的DTO命名习惯，比如用户对象都叫UserInfoVO，属性名保持完全一致。这样省去了大量的"这个字段改个名"的时间。

4. 调试部署与文档交付全流程

4.1 本地调试环境的搭建细节

本地调试环境的核心准备工作有：JDK（建议8或11）、Maven（3.6以上）、MySQL（5.7或8.0）、Redis（可选）、Node.js（14以上）。

MySQL导入数据库脚本时经常遇到字符集问题，中文显示乱码。解决方式是在连接URL里加上?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai这一长串参数。另外数据库本身也要设置成utf8mb4字符集。这个坑几乎每个人都会踩一遍。

后端启动如果碰到端口被占用，直接在application.yml里改server.port即可。如果碰到数据库连接失败，先检查数据库账号密码和URL是否一致。如果引入Redis连不上，建议把Redis的地址和密码先配成与本地一致，或者直接把相关缓存的代码注释掉，先把主体业务跑通。

前端npm install有时候会非常慢，可以使用国内镜像源。安装完后npm run serve启动，默认端口要留意Vue CLI输出的是多少。如果8081端口被占用，Vue CLI会默认切换端口，别在浏览器死磕8081。

4.2 项目打包与上线部署

前端的打包命令是 npm run build，产物是dist目录。把dist里的静态文件交给Nginx托管即可。Nginx配置里最核心的一条是：把 /api 开头的请求反向代理到后端的http://localhost:8080，并且要配置proxy_set_header Host $host防止后端拿到的Host头不对。

后端打包用的是Maven的package命令，产物是jar包。运行方式：java -jar xxx.jar，后台运行可以用nohup。如果服务器内存紧张，加上-Xmx256m限制Java堆内存。

我记得有一种情况很容易让人抓狂：前端部署后页面能打开，但所有接口都404或502。基本原因就是Nginx的代理路径写错了。比如后端接口实际路径是/api/product/list，前端请求的也是/api/product/list，那代理规则必须是location /api/ { proxy_pass http://127.0.0.1:8080/; }注意proxy_pass结尾要不要带斜杠会影响路径拼接，建议调试时先直接在服务器上curl后端接口确认后端正常，再排查代理。

4.3 项目文档的编写方法论

文档是这个项目交付物里容易被忽略但实际占分不小的部分。一篇合格的毕设/课程设计文档至少包含：需求分析、系统设计（架构图+功能模块划分）、数据库设计（ER图+表结构说明）、接口设计、核心代码实现说明、系统测试、项目总结。

写数据库设计时不要光贴建表SQL，要给每个核心字段加注释解释业务含义。比如orders表里的status字段，每个数字代表什么状态必须说明清楚。写接口设计时建议把每类的请求方式、路径、请求参数、返回结果都列出来，一两个核心接口配上时序图。答辩时老师大概率会翻开文档问：你这个接口为什么返回的是一个自定义Result对象？所以建议设计一个统一返回体{code, message, data}，并在文档里给出定义。

项目测试部分不要只写"测试通过"四个字。建议按功能模块列测试用例：正常流程、异常流程、边界条件（比如库存不足、未登录访问购物车）。测试用例表在文档里会非常加分，它体现的是你的工程化思维，而不仅仅是编码能力。

4.4 答辩时的功能演示与讲解路径

答辩演示顺序建议按"用户视角"走一遍完整闭环：注册新账号 → 登录 → 在首页浏览商品 → 搜索关键字 → 进入详情页选择SKU → 加入购物车 → 结算下单 → 模拟支付 → 查看订单状态 → 切管理员账号在所有模块看到对应数据变化。整个过程自然流畅，不需要刻意讲代码，先把业务闭环讲清楚。

讲解时几个高频提问点，需要提前准备好：

• 为什么用JWT而不是Session？答：前后端分离架构下Session不方便管理，服务端不保存状态，扩展性好，Client端存储Token，减轻服务端内存压力。
• 库存超卖怎么防止？答：用带条件的UPDATE乐观锁方案，保证并发扣减时只有一个事务成功。
• 购物车为什么能支持不登录？答：实际上这个项目是登录后才能加购（这是后端拦截器控制的）。如果你非要支持未登录加购，可以考虑存localStorage，但登录后需要把本地的购物车合并到服务端。这个逻辑复杂度会成倍增加，不建议做。
• 订单号怎么生成的？答：建议用"时间戳+随机数"或者"日期+自增序列"，推荐用Snowflake算法的简化版，保证全局唯一且有序。

5. 常见问题与排查技巧实录

5.1 高频踩坑问题与解决方案速查表

5.2 几个值得记住的实用调试技巧

第一个技巧是学会看日志找问题。SpringBoot默认的日志会输出SQL执行语句。如果在日志里看到==> Preparing:开头的SQL，说明MyBatis-Plus已经执行到数据库了。此时SQL不对，查Mapper的注解或XML；如果连SQL都没有，说明你的代码在进入Mapper之前就抛异常了。这是排查"为什么数据没写进去"最快的路径。

第二个技巧是善用Postman做接口测试。每写完一个后端接口，立刻在Postman里调一遍，确认返回JSON符合预期再去做前端联调。这样可以把前端联调时的问题缩小到"纯粹的前端代码问题"，而不是前后端一起猜。我见过太多人一上来就写前端页面，一个接口错了前后端一起查，查了半天发现是后端密码加密方式变了前端还在用明文对比。

第三个技巧是因项目而异的：修改后端代码后，如果是热的，IDEA的DevTools会自动重启；如果不是，请重启SpringBoot应用。很多人改了代码发现没生效，以为写的逻辑不对，其实只是没重启。前端同理，npm run serve的HMR热更新偶尔也会失效，无效时就刷新页面或重启dev server。

5.3 提升项目完成度的几个小细节

完成度是什么？是在同样的技术栈和功能清单下，你的项目给人的"成熟感"。下面几个小细节能显著提升这种感觉：

• 全局异常处理。把参数校验异常、业务异常、未知异常统一由一个@RestControllerAdvice处理，返回统一格式的JSON。这样前端拿到的永远是这个格式，而不是一堆乱七八糟的报错堆栈。
• 统一的状态码。业务成功是200，参数错误是400，未登录是401，无权限是403，服务器错误是500。后端要有自己的一套业务码和消息字典，这不难写，但大部分同学没做。
• 前端加载状态。列表页或详情页的数据加载过程加一个loading遮罩，虽然是小细节，但观感直接上升一个档次。
• 空数据页占位。购物车为空、订单列表为空时，不要只显示一个空白屏，给一张小图和一句"购物车还是空的，快去逛逛吧"。

5.4 关于性能优化和后续扩展的思考

这个项目做完以后，我自己回顾了一遍，如果要给它做性能提升，我会从三个角度入手：第一，商品详情页增加Redis缓存，用户每次刷新页面不用打数据库；第二，引入RabbitMQ削峰，模拟秒杀场景的压力下，订单创建和库存扣减通过消息队列异步处理；第三，MySQL主从分离，读操作走从库，写操作走主库，用MyBatis-Plus的读写分离插件实现。

这些方向不需要在课程设计阶段全部做，但在项目总结部分把这些作为"待优化项"写出来，会让老师觉得你对这个系统的演进是有清晰认知的。课程设计与工业级系统的区别，本来就在于工程复杂度和并发场景，知道自己的系统在哪些地方有所简化，本身就是一种专业的表现。

6. 写在最后的一些经验和建议

我在这个项目反复打磨的过程中，最大的体会是：做这类全栈管理系统，真正的难点从来不是某个技术点不会，而是"几十个功能点如何在有限时间内全部串起来不打架"。它考验的是拆解能力——你能不能把一整个商城拆成用户、商品、购物车、订单、后台五个独立模块，每个模块单独做通，再通过接口把它们串成完整业务闭环。只要前期表结构和接口约定做清楚了，编码本身就是一个体力活。

另外一个很实在的建议是：一定要给自己留出至少三天的缓冲时间用来联调和写文档。功能代码写到最后，所有人都会发现"时间不够了"。前端和后台联调出的各种小问题、部署环境的不一致、文档缺图缺描述，每一个都会吃掉大量时间。提前把环境固定下来，把接口约定固定下来，把文档框架提前搭好，后面的调试就会顺利很多。

如果你正准备按这个方向做，或者已经在开发途中遇到某个具体问题卡住了，这篇文章里的内容都是可以直接拿来参考的。尤其是表设计、订单状态流转、库存扣减SQL和跨域代理配置这几块，是我反复修改之后沉淀下来的最优解。照着做，至少能让你少走几个弯路。