SpringBoot+Vue电商商品管理系统全栈实战与避坑指南

从去年开始，陆陆续续被好几个准备毕业设计的学弟学妹问过同一个题目：SpringBoot + Vue的电商商品管理系统。说实话，刚听到这个题目时觉得有点“大众”，但真做下来的人都知道，这个题目其实是全栈项目里性价比最高的一类——它不要求你硬啃高并发中间件，却能把后端接口设计、前端组件通信、权限控制、文件上传、订单与库存联动这些真实开发链路完整跑一遍。我自己的感受是，认真做完这个系统，你对“项目”这两个字的理解会比刷一百道面试题都管用。

今天这篇内容，我不打算按那种“第一章绪论、第二章需求分析”的论文体来写，而是围绕一个真正能跑、能答辩、能拿出去说的商品管理系统，把从设计到部署的完整思路、核心代码怎么写、容易踩的坑在哪，以及面试答辩时老师最爱问的几个点都拆开讲清楚。全程尽量说人话，凡是能直接复用的代码片段、接口思路和部署命令我都会放到对应的段落里。

1. 别急着写代码：先把数据模型钉死，后面才不会被自己坑

很多同学拿到这种项目喜欢先搭框架、先写一个用户登录，然后一边写一边补表。我强烈建议反过来，用两到三个小时把业务梳理清楚，把表结构和接口边界定下来再动手。商品管理系统虽然看起来就是“增删改查”，但它的核心难点恰恰在表关系上。

1.1 商品系统最核心的四张表，以及它们之间的关系

一个电商后台的商品模块，往下拆无非是：用户、商品、分类、库存、订单、订单明细。如果希望系统信息完整一点，再加上购物车、收货地址、轮播图、公告之类的辅助表。这里我先给出最核心的四张，它们基本决定了项目的主体复杂度。

我见过不少毕设项目把价格字段设为VARCHAR，理由是“怕精度丢失”或者“数据库里不想看到小数”。这种思路在毕设里能走通，但答辩时被问到“为什么用字符串存价格”会非常尴尬。正确做法是：金额用整数存储，单位是“分”，展示时再除以100转成“元”。这个设计既绕开了浮点数精度问题，又显得你有真实项目经验，是一笔非常划算的印象分。

还有一个小细节：product表里一定要有sales（销量）字段，每次订单完成时把明细表里的数量累加进来，前端展示“已售xx件”就直接查这个字段，不用去全表SUM，性能好得多。别问，问就是有人真在列表页里嵌套查询了订单表，结果商品几百条的时候页面就开始卡了。

1.2 商品和分类的前后端联动：为什么会“删不掉已上架的商品”

表结构定了之后，第一个业务痛点就来了：删除分类时，如果这个分类下面还有商品怎么办？删了商品，分类会留下孤儿数据；不删，分类就永远清不掉。

我的处理方式是物理加一个逻辑删除标记。具体做法是在category表加一个is_deleted字段，删除分类时先检查product表中是否还有使用该分类且未删除的商品，存在则提示“该分类下存在商品，无法删除”，否则将分类标记为已删除。product表同理，下架商品用status=0表示，而不是直接DELETE；只有管理员在“回收站”功能里二次确认时，才会真正物理删除。

这么设计的好处有两个。一是数据安全，避免误删导致用户下单时引用不存在的商品ID；二是在答辩时，你可以非常自然地说出“逻辑删除保证数据可追溯，物理删除只用于管理员明确清理”这样有实践深度的结论。类似这一点点细节，往往就是项目评分拉开差距的地方。

2. SpringBoot后端：从商品SKU到库存扣减，核心接口到底怎么设计

后端部分，我建议按模块分Package来写：controller、service、mapper、pojo、common、config、utils各司其职。这里不展开整个工程的目录结构，重点挑两个最容易出彩也最容易出错的模块来说。

2.1 商品列表的分页查询：参数校验要比“能查出来”更重要

商品列表是本系统出现频率最高的接口，也是面试官和答辩老师几乎必看的一个接口。很多同学会写成这样：

java复制@GetMapping("/list")
public Result list(@RequestParam Integer pageNum,
                   @RequestParam Integer pageSize,
                   String keyword,
                   Long categoryId) {
    PageHelper.startPage(pageNum, pageSize);
    List<Product> list = productMapper.selectByCondition(keyword, categoryId);
    return Result.success(new PageInfo<>(list));
}

这个写法本身没错，PageHelper也是官方推荐的分页插件，细节在于它背后的几个隐藏问题。

第一个是关键词搜索可能包含SQL注入风险。我建议keyword进来之后先做一次trim和特殊字符过滤，或者直接用MyBatis的#{keyword}参数绑定，永远不要用${}拼SQL。第二个是当categoryId传了一个根本不存在的分类ID时，接口不应返回空列表，而应返回“分类不存在”的明确提示。第三个是排序问题：后台商品列表一定要有“上架时间倒序”和“销量倒序”两种排序方式，前端切换排序时通过sort参数指定，排序字段做白名单校验，只允许传approved值。

还有一点容易被忽略：分页查询接口返回的商品对象，不应该带着detail大文本字段。product表里的detail是富文本或长文本，哪怕为空也会占用数据库IO。正确的做法是额外出一个product_detail表，或者在查询时用SELECT id, name, price, main_image, ...显式字段，而不是SELECT *。这些虽然不影响功能，但答辩时一旦被问到“性能优化做了什么”，你就可以指着这一条说：列表页避免了长文本字段的冗余加载，详情页再按需查询。

2.2 商品上架/下架的状态机：别让状态字段变成野马

商品状态我定义为：0-下架，1-上架，2-审核中。这里为什么多一个“审核中”？因为如果系统面向的是实际运营场景，后台管理员上架商品前通常需要运营审核。虽然毕设里不一定做完整的审核流程，但预留这个状态会让你在答辩时有很大的发挥空间。

先给出一个状态机的约束逻辑：只有审核中的商品可以变更为已上架或下架；已上架商品只能变更为下架；已下架商品只能变更为审核中或删除。这个规则在Controller层先用if判断一次，然后在Service层再判断一次，最后在数据库层面用UPDATE product SET status = #{newStatus} WHERE id = #{id} AND status = #{oldStatus}再兜底一次。三层校验的好处是，即使前端页面绕过按钮直接调接口，也无法把商品从一个非法状态变到另一个非法状态。

顺带说一件我在给别人review代码时经常发现的问题：很多人喜欢把状态判断写在校验里，比如：

java复制if (product.getStatus() == 1) {
    throw new RuntimeException("商品已上架，无法重复上架");
}

这种写法不是不行，而是异常类型和提示语太粗糙。我建议用自定义BizException，并配合全局异常处理器统一返回Result.error(code, message)结构。否则前端拿到一个500状态码，根本不知道是业务错误还是系统异常，排查问题会非常痛苦。

2.3 库存扣减的经典陷阱：为什么你的库存超卖了

库存扣减是电商项目的灵魂逻辑，也是这个题目里最值得深挖的技术点。

先看一个最直观的错误写法：

java复制@Transactional
public void createOrder(Long productId, Integer quantity) {
    Product product = productMapper.selectById(productId);
    if (product.getStock() < quantity) {
        throw new BizException("库存不足");
    }
    product.setStock(product.getStock() - quantity);
    productMapper.updateById(product);
    // 创建订单、持久化订单明细...
}

这段代码问题非常明显：先查询库存，再判断，再更新，三步之间存在时间差。在低并发演示时一切正常，但只要有两个请求同时读到库存为10，同时各自扣减5，最后库存可能只剩5，而两张订单却都创建成功了——这就是标准的超卖。在单机、单实例部署的毕设环境里，这个问题不一定会暴露，但答辩现场如果老师让你用JMeter压一下，或者问“扣库存时并发怎么办”，你的应对能力就直接决定了评分档次。

正确的做法有几种，我分别说明：

1. 数据库乐观锁方案，用version字段配合条件更新：

sql复制UPDATE product SET stock = stock - 5, version = version + 1
WHERE id = #{productId} AND stock >= 5 AND version = #{oldVersion}

这种方式在Affected rows = 0时说明库存不足或版本冲突，再返回“库存不足”，事务回滚。它的好处是不需要额外引入中间件，毕设完全够用。

2. 数据库悲观锁方案，查询时加FOR UPDATE锁定行：

sql复制SELECT * FROM product WHERE id = #{id} FOR UPDATE

这种方案在事务中有效，保证同一时刻只有一个事务能读到该行库存，但也带来了行锁等待问题，性能上略差，且锁一定要在事务中才能生效。

3. Redis+Lua原子扣减方案：把库存预热到Redis，用Lua脚本保证查询和扣减的原子性。这个方案是互联网大厂的标准做法，但毕设引入Redis会让项目复杂度上一个台阶。如果你学有余力，我建议作为加分项在论文里提一句“考虑到性能和系统扩展性，未来可以引入Redis缓存库存”，但实际项目中不必强行落地。

我的个人建议是：核心代码采用方案1，用乐观锁解决并发超卖；把方案2和方案3作为你说服老师“我做过并发思考”的素材，不要都写到代码里。这里也体现了工程思维中“引入新技术要衡量维护成本”的取舍。

2.4 事务边界与自调用失效：一个必考的Spring冷知识

在库存扣减、订单创建过程中，事务是必须的。@Transactional注解的默认传播行为是REQUIRED，也就是如果一个事务已经存在，就加入当前事务，否则新建事务。这本身没问题，但有一个著名的坑：自调用失效。

什么叫自调用失效？看下面这个例子：

java复制@Service
public class OrderServiceImpl implements OrderService {

    // 同一个类内部的调用，事务不会生效
    @Transactional
    public void createOrder(OrderCreateDTO dto) {
        deductStock(dto.getProductId(), dto.getQuantity());
        saveOrder(dto);
    }

    public void deductStock(Long productId, Integer quantity) {
        // 扣库存逻辑
    }
}

当外部调用createOrder时，事务A开启；但createOrder内部直接调用同类deductStock方法时，这个调用并没有经过Spring的代理对象，而是直接走当前对象的方法，所以deductStock上的@Transactional根本不会生效。开发时大家都察觉不到，因为createOrder自身是在事务里的，扣库存的错误会连带整体回滚。但如果你把deductStock单独对Controller暴露成接口，事务就会失效。

解决自调用失效的标准方案是：把需要事务的方法放到不同Service中，或者注入自身的代理对象AopContext.currentProxy()。这个知识点面试频率极高，如果你能在项目代码里注意到这一点，等于提前给答辩埋了一个“加分问答点”。

3. Vue前端：路由划分、状态管理和SKU选择器的实战经验

前端部分我用Vue 2 + Element UI来举例（这个组合在毕设里最常见，教程也最多，如果你们要求Vue 3，那换成Element Plus即可）。这个项目里前端最重要的工作是商品列表页、商品详情页、下单页，以及后端的商品管理页。

3.1 路由设计：为什么建议把后台和商城页面拆成两个布局

商品管理系统是典型的前后台混合系统：普通用户看到的是商城端（首页、商品列表、详情、购物车、订单），管理员看到的是管理端（商品管理、分类管理、订单管理、用户管理、数据统计）。这两端页面风格差异很大，如果混在同一套布局里，路由守卫和侧边栏逻辑会非常乱。

我的做法是用两个根组件分别承载两端：

javascript复制const routes = [
  {
    path: '/',
    component: Layout,           // 商城端布局
    children: [
      { path: '', component: Home },
      { path: 'product/:id', component: ProductDetail }
    ]
  },
  {
    path: '/admin',
    component: AdminLayout,      // 管理端布局
    meta: { requiresAdmin: true },
    children: [
      { path: 'product', component: AdminProduct },
      { path: 'category', component: AdminCategory }
    ]
  }
];

路由守卫这里我多说一句：前端判断用户是否登录，不能只靠localStorage里有没有token，因为token过期后接口一样会401。正确做法是在全局路由守卫里先检查token是否存在，并结合/admin前缀做角色判断；同时在axios的响应拦截器里统一处理401状态码，一旦拿到401就清除本地登录状态并跳回登录页。

很多同学的毕设只会做“登录后显示按钮”这种假拦截，导出一个只有前端页面的演示视频时看不出问题，但评委现场试了一下直接访问/admin/product，你会发现系统居然能打开管理页面。这个细节一旦被当场试出来，项目评价会打很大折扣，所以路由守卫+接口权限校验一定要同时做。

3.2 商品列表页的状态设计：加载中、空视图、错误态缺一不可

商品列表页是最常被老师反复操作调试的页面。前端在请求接口时，要考虑三种状态：加载中、加载成功有数据、加载成功无数据（或接口报错）。

我推荐的实践是：

• 用loading变量控制表格或卡片的loading状态；
• 用dataList.length === 0渲染空视图；
• 用errorMsg渲染接口异常提示，并提供“点击重试”按钮。

这些看起来很简单，但如果漏掉加载中状态，接口慢的时候用户会以为页面卡死；漏掉错误态，后端接口报错时页面上会是一整片空白，调试成本极高。写商品管理系统时顺便把这三个状态做全，不仅是体验问题，也会在你之后找工作写项目经历时变成“我注重前端边界情况处理”的素材。

另外，商品列表页的筛选条件（关键词、分类、价格区间、排序）需要和URL参数联动。我建议把筛选条件放在路由query中，例如/product/list?keyword=手机&categoryId=3&sort=price_asc。这样做的好处是刷新页面后筛选状态不丢失，而且分享链接时别人看到的是同一个筛选视图。这个细节在毕设演示时特别能打出“设计感”。

3.3 SKU选择器：规格组合如何处理才不显得业余

有些商品管理系统只需要维护简单商品，但如果想做亮眼一些，可以引入多规格SKU。比如一件T恤有颜色（黑/白/蓝）和尺码（S/M/L）两个规格维度的组合，每种组合有独立的库存和价格。

SKU的核心设计是：前端用specList数组保存所有规格选项，选中规格时通过下标组合定位到唯一的SKU，再从SKU列表中取出这个组合对应的价格、库存、图片。后端product_sku表可以设计为：

sql复制CREATE TABLE product_sku (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  product_id BIGINT NOT NULL,
  specs VARCHAR(255) NOT NULL COMMENT 'JSON字符串：{"颜色":"黑色","尺码":"M"}',
  price INT NOT NULL COMMENT '价格，单位分',
  stock INT NOT NULL DEFAULT 0,
  status TINYINT DEFAULT 1
)

在Vue里，我用一个Map结构来快速索引SKU：key是黑色-M，value是对应的SKU对象。用户点击规格按钮时，前端能立刻更新展示区域里的价格和库存，而不需要重新请求后端。下单时直接把SKU ID传给服务端，由后端重新校验规格和库存是否匹配，避免前端伪造价格。

这个功能在普普通通的增删改查项目里非常亮眼。但我要提醒一句：如果时间紧张，宁可不做SKU也要保证商品基本流程完整；如果不做SKU，就不要在答辩时硬把规格属性塞进product表里，那样反而显得为了“加功能”而“加功能”。

4. 图片上传与文件访问：毕设里最容易翻车的隐形坑

商品管理系统一定绕不开图片上传，商品主图、轮播图、分类图标全都涉及文件。这个模块我见过最多的问题就是：图片上传成功了，但页面一刷新图片就404。

4.1 为什么“上传成功但图片不显示”会频繁发生

最常见的原因是开发时把文件保存到了SpringBoot项目的src/main/resources/static/upload目录。本地调试时一切正常，因为idea会把你本地磁盘的目录映射出来；但打成jar包部署后，上传的文件写进了jar包内部或者一个临时目录，重启后原来的文件路径就丢失了。你在idea里跑了三个月，觉得图片功能很完美，结果部署到服务器上一演示，之前上传的图片全部失效。

这件事的本质问题是把“代码目录”当成了“文件存储目录”。代码和静态资源混在一起，一旦重新部署，代码目录被替换，图片就跟着没了。

4.2 解决办法：独立存储目录 + Nginx静态映射

正确的做法有两条路径。

第一条是本地存储方式：在application.yml里配置一个独立的文件存储路径，比如Linux下的/data/upload、Windows下的D:/upload，这个路径和项目代码完全无关。上传接口收到文件后，用UUID或时间戳重命名，防止文件名重复和路径穿越攻击，然后保存到独立目录，并把可访问的URL（比如/images/xxx.jpg）存入数据库。

还需要新建一个WebConfig类，把虚拟路径映射配好：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Value("${file.upload-path}")
    private String uploadPath;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/images/**")
                .addResourceHandler("file:" + uploadPath);
    }
}

注意file:前缀必不可少，它告诉Spring这是一个磁盘路径，否则映射不生效。

第二条是直接改成OSS等云存储。虽然毕设一般不推荐花钱配OSS，但如果你能写到毕业论文的“系统优化与展望”里，说“为了提高图片访问速度和可用性，生产环境可以将图片迁移至对象存储并搭配CDN”，这句话的含金量非常高。

另外还有一个安全细节：上传接口必须做文件类型白名单校验，不能只信任前端传的Content-Type。攻击者可以伪造multipart/form-data里的Content-Type为image/png上传一个可执行文件，后端如果按原始文件名保存并对外开放访问，等于给服务器开了一个后门。我用的是后缀白名单（.jpg/.jpeg/.png/.gif/.webp），同时限制文件大小不超过5MB，超过则抛“图片不能超过5MB”的提示。

5. 订单与库存的一致性：从“演示能跑”到“逻辑严谨”的进阶设计

商品系统如果只到后台管理就收工，那项目深度是明显不够的。真正让这个系统“活”起来的，是用户下单这条链路：加入购物车、提交订单、扣减库存、生成订单明细。

5.1 为什么前端校验了库存，后端还要再校验一次

我见过有的同学把库存校验放在前端，判断逻辑是“如果商品库存大于0就允许下单”。看似没问题，可用户只要绕过前端直接调用后端接口，就能在库存为0时照样下单。

后端校验库存是底线，但光有个if判断还不够。如果把前面讲的乐观锁方案落地，校验和扣减应该是同一个原子操作。以下是Service层的扣减逻辑核心：

java复制@Transactional
public void createOrder(Long skuId, Integer quantity, Long userId) {
    // 1.校验SKU是否存在且上架
    Sku sku = skuMapper.selectById(skuId);
    if (sku == null || sku.getStatus() != 1) {
        throw new BizException("商品不存在或已下架");
    }

    // 2.乐观锁扣库存
    int affected = skuMapper.deductStock(skuId, quantity);
    if (affected == 0) {
        throw new BizException("库存不足");
    }

    // 3.创建订单主表
    // 4.批量创建订单明细
    // 5.针对积分、销量等字段做后续联动
}

这里第2步的update语句写法是：

sql复制UPDATE product_sku
SET stock = stock - #{quantity}
WHERE id = #{skuId} AND stock >= #{quantity}

affected为0说明库存不够，直接回滚整个事务并抛出业务异常，不会出现超卖。这套方案在并发时的正确性是经过验证的。

5.2 订单状态到底该有几种：从“已支付”到“已发货”的流转闭环

订单状态我推荐这样设计：0-待支付，1-已支付/待发货，2-已发货，3-已完成，4-已取消。有任何一步漏了，都会导致管理后台的订单操作无法闭环。

状态机的维护点在两个地方：一是用户端“取消订单”只能发生在待支付状态；二是管理端“发货”只能发生在已支付状态。尤其要注意的是，取消订单时需要把已扣减的库存加回去，这一步也必须放在事务中，否则会出现“订单取消了，库存却没恢复”的数据不一致问题。

这里还有一个我踩过的坑：如果用户先加入购物车，数量是5；管理员在后台上把库存改成2；然后用户提交订单并支付。此时订单已经生成，商品库存也已经扣减。你在后台看到的现象是“商品库存变成了-3”。我在这个系统里加了一步“支付前检查最新库存”，支付时如果发现库存被改小导致扣减失败，会提示“商品库存发生变化，请重新下单”。虽然商业上这么做不一定对，但毕设里这种保护性设计能明显体现出你考虑了数据边界条件。

5.3 如果非要引入Redis做分布式锁，那我建议你这样做

既然前面提到了超卖问题，我来聊聊毕设要不要上分布式锁。很多同学的毕设里其实只有一个后端实例，用synchronized都能在网上商城这小流量下保持正确性。但后面面试或答辩时主动说“我用的是Redis分布式锁”，就必须搞清楚何时需要它。

一个判断标准很简单：如果你的系统部署了多个实例副本，或者未来打算拆成微服务，那么各节点之间的synchronized互不感知，分布式锁才有意义。毕设中通常不需要，但如果你学有余力，想把这个项目作为找实习的敲门砖，我建议把Redisson引入，只用于库存扣减前的那一步：

java复制RLock lock = redissonClient.getLock("stock:lock:" + skuId);
boolean tryLock = lock.tryLock(3, 10, TimeUnit.SECONDS);
if (!tryLock) {
    throw new BizException("系统繁忙，请稍后再试");
}
try {
    // 扣库存 + 创建订单
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

注意锁的粒度是skuId，不要锁整个商品或者锁全库订单表，否则高并发下所有商品下单都会互相阻塞。用Redisson的好处是它自动处理了锁的过期续期和Redis宕机等问题，比你自己用SETNX实现一个简易锁要可靠得多。

不过这里我建议你保守一些：如果答辩老师不是特别倾向分布式方向，不要主动把“分布式锁”写进核心功能描述。只要在你的README或论文“系统设计”部分提到“重试机制+乐观锁已避免超卖，针对多实例部署可扩展分布式锁”，已经能拿高分了。

6. 从本地运行到答辩演示：部署配置、安全基线和面试考点速览

6.1 前端打包放进SpringBoot：三种部署方式怎么选

商品管理系统做完后，摆在面前的是部署选项。我知道八成同学会直接把dist目录扔到SpringBoot的static目录下，打成单个jar包，一台服务器全搞定。这个方案对毕设确实最省心，操作如下：

在Vue项目根目录执行npm run build，把生成dist里的文件复制到SpringBoot的src/main/resources/static下，重新build SpringBoot工程，再java -jar xxx.jar运行。这样访问http://IP:8080/会直接进入前端页面，接口走的是同域名的/api路径，不需要处理跨域问题。

但如果你想在简历上多写一句“服务器部署经验”，我更推荐第二种方式：前后端分离部署。前端dist放到Nginx的html目录，Nginx托管静态资源并把/api反向代理到SpringBoot的8080端口。Nginx配置核心片段：

nginx复制server {
    listen 80;
    server_name yourdomain.com;

    location / {
        root /usr/share/nginx/html;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

try_files那行务必写上，否则前端刷新页面或直接访问子路由时，Nginx会返回404。这个坑我当年自己折腾了一个多小时才想明白。

第三种方式是前后端都打包进容器，用Docker Compose一键拉起Nginx和Java进程。如果时间充足，这会是不错的加分项，但注意别在答辩现场直接演示Docker，一旦镜像拉取超时或端口冲突，现场会很难收场。我一般建议生成一个docker-compose.yml文件放到项目里，作为“工程化能力”的陈列品，不一定要实时演示。

6.2 登录认证与接口安全：别让任何用户乱调管理接口

商品管理系统的权限控制是本项目的安全底线。后端我推荐Spring Security + JWT的方案，或者更简化一些，自己用拦截器校验Token和角色。

最基础的链路是：用户登录成功后生成JWT，包含userId和role字段，token返回前端；前端请求时放到Header的Authorization里；后端拦截器解析token，得到当前用户信息，再判断角色是否为ADMIN，决定能否访问/admin/**接口。

这里有两个坑：

第一个坑是JWT的密钥不要硬编码在代码里，应放到application.yml或环境变量中。另一个是JWT一定要设置过期时间，一般建议2小时。如果用户的登录态永不过期，那这个系统的安全问题非常严重。

第二个坑是只校验“是否登录”，不校验“角色是否匹配”。比如商品新增接口只要求登录用户就能访问，那普通用户就可以伪造请求添加商品。正确的做法是角色判断必须在后端拦截器或方法级注解里做：

java复制@PreAuthorize("hasRole('ADMIN')")
@PostMapping("/admin/product")
public Result addProduct(@RequestBody ProductDTO dto) {
    ...
}

哪怕前端路由守卫已经做了角色控制，后端权限依然是最后一道防线。把这两层分开写清楚，答辩时老师问“你的系统怎么保证普通用户不能操作后台”时，你可以从路由守卫、拦截器、接口级权限三层来回答。

6.3 答辩高频考点：这些坑你一定要提前准备

最后一部分，我把它当“送分清单”整理出来。这个项目答辩时，老师几乎必问以下问题，你要能随口答上来：

1. 表设计为什么这么设计？——答：每个表都有明确职责，订单和订单明细拆分是为了不冗余记录商品信息，使用逻辑删除保证数据可追溯。
2. 购物车如何避免重复提交？——答：前端提交按钮禁用，后端幂等表校验（在order表里加唯一约束order_no，同一次请求返回同一结果）。
3. 为什么用乐观锁解决库存超卖？——答：乐观锁用version字段控制并发，无需引入锁服务，性能好且满足当前系统并发量。
4. Redis缓存如何避免穿透、击穿、雪崩？——答：穿透用缓存空对象或布隆过滤器，击穿用互斥锁更新，雪崩用随机过期时间+多级缓存。即便你实际只用了基本缓存，也要能把这套思路说出来。
5. 接口怎么防止恶意频繁请求？——答：前端按钮防抖+后端简单IP限流（通过拦截器统计时间窗口内请求次数，超过阈值返回429）。
6. 数据库索引怎么建的？——答：商品表对category_id建普通索引，订单表对user_id和status建组合索引，订单明细表对order_id建索引。
7. JWT和Session有什么区别？——答：JWT无状态、可跨域、天然适合前后端分离，但无法主动失效；Session有状态、占用服务端内存，适合传统应用。

需要说明的是，这些问题不是背下来就算过，关键是回答时能和自己的项目代码对上。比如说到乐观锁，就一定要能说清楚项目里是哪一段SQL用了这个方案；说到JWT，要能指出代码里哪个拦截器解析的Token。只有代码和理论互相对应，才能让老师相信这是你自己动手写的项目。

7. 最后的个人体会：这个系统的真正价值，不在于功能多华丽

我之所以反复推荐这个题目，是因为它是一条捷径：项目难度适中、知识点覆盖面广、面试复盘收益高。但前提是你真的动手写，而不是把网上开源项目down下来改个名。

写代码的过程中你会遇到很多“文档上没写”的问题：为什么上传的图片刷新后消失、为什么同一个类的@Transactional不生效、为什么Nginx刷新后404、为什么Postman测试通过但浏览器带Cookie失败……这些问题每一个都会让你对这个系统背后的原理有更深的记忆。做了这个项目，你的收获是体系化的：数据库由表先行的设计习惯，后端从接口到事务的严谨边界，前端从状态管理到路由守卫的细节处理，再到部署时Nginx的配置踩坑。这套能力栈正是现在业务开发最常用的核心组合。

如果你正打算拿这个题目开题，我最后只有一句建议：先用一天时间把表结构和接口清单列清楚，再动键盘。表结构定了，联调时你会感谢自己；表结构乱了，那后面的每一个功能都是在给自己埋雷。希望这篇拆解能帮你在毕业设计这条路上少踩几个坑，做出一个真正经得起演示、经得起提问、也经得起自己日后回看的作品。