SpringBoot+Vue网上超市系统实战：从设计到部署全流程解析

做网上超市这种管理系统，我觉得是Java后端和前端入门最值得动手的练手项目之一。它不像纯粹的学生管理系统那样只有一个增删改查，也不像完整电商平台那样动辄秒杀、分布式、消息队列，它刚好卡在中间：包含用户注册登录、商品浏览、购物车、订单、后台管理等完整业务闭环，同时又能用一套主流的 SpringBoot + Vue 技术栈全部搞定。我在做这套东西的时候，前前后后重构过三版，踩过的坑基本都在意料之外又在情理之中，这篇就把我最终落地的那套方案拆开写给你。

如果你是拿它做毕业设计、课程设计，或者刚学完 Java 和 Vue 想找一个“完整项目”练手，这篇内容可以直接照着搭。我会把技术选型的原因、数据库表怎么设计、后端接口怎么写、前端页面怎么对接，以及实际开发中那些文档里不会写的问题排查经验，全部讲清楚。

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

1.1 为什么是 SpringBoot + Vue，而不是其他组合

现在网上课程设计项目一搜一大把，但大多数还停留在 JSP + Servlet 或者 SSM + 模板引擎 那套老古董上。不是说老技术不行，而是你做完之后会发现，找工作也好、做毕设答辩也好，面试官基本已经默认你会 SpringBoot 和 Vue。SpringBoot 解决了传统 SSM 配置地狱的问题，内嵌 Tomcat、自动装配，几行配置就能跑起来；Vue 则把前后端分离开发这件事变成了行业标准，前端通过 axios 调后端接口，职责清晰，也更容易让你理解企业里“接口对接”到底是怎么回事。

MySQL 作为数据库，配合 MyBatis 做持久层，这套组合在中小型管理系统里非常常见。MyBatis 的好处是把 SQL 写在 XML 或者注解里，你能完全掌控 SQL 执行过程，性能调优空间大，面试也爱问“MyBatis 一级缓存二级缓存”“#{} 和 ${} 的区别”这类问题。既然你做的是完整项目，那就顺便把这些知识点在实战中吃透，面试讲起来才有说服力。

1.2 系统分层架构与模块划分

网上超市系统，我把它拆成了两个端、六大模块。两个端分别是用户端和管理员端，前后端分离，共用一个后端服务。六大模块包括：用户模块（注册、登录、个人信息）、商品模块（分类、列表、详情、搜索）、购物车模块（加入、修改数量、删除、结算）、订单模块（创建订单、订单列表、订单详情、取消订单）、地址管理模块（收货地址增删改查）、后台管理模块（商品管理、分类管理、订单发货、用户管理）。

后端我用的是经典的三层架构，Controller 负责接收请求和参数校验，Service 负责业务逻辑，Mapper（DAO）负责数据库交互。实体类对应数据库表，DTO 负责接口参数的接收和返回，VO 负责给前端展示的数据封装。这种分层在项目里看着麻烦，但好处是出了问题非常好排查：接口报错先看 Controller 参数，业务不对看 Service 逻辑，SQL 错了看 Mapper XML。我见过不少同学把所有代码堆在 Controller 里，一个类一千多行，后面改需求改到崩溃，这是绝对要避免的。

前端技术选型上，我用的 Vue2 + Vue Router + Vuex（或 Pinia，看你的 Vue 版本）+ Element UI。Element UI 是饿了么开源的后台组件库，表格、表单、弹窗、分页、导航菜单这些都直接有现成组件，做后台管理界面效率极高。用户端为了更接近真实超市的浏览体验，商品卡片、购物车侧边栏这些会手写一些样式，整体风格简洁清爽即可。

2. 数据库设计与核心表结构

2.1 核心表清单与设计思路

数据库设计是这种管理系统的灵魂。网上超市如果表设计不合理，到了写 SQL 阶段就是灾难，尤其是订单和商品的关系、库存扣减的时机，必须先想清楚。我这套项目的核心表一共有 8 张：

订单和订单明细为什么要拆成两张表？因为一个订单可能包含多个商品，如果直接冗余在订单表里，字段会变得特别乱，而且一个订单的商品数量无法确定，表结构根本没法固定。拆成主表和明细表之后，一对多关系就变得清晰了。还有一个关键细节是“地址快照”：订单表里存了 address_snapshot 字段，把下单那一刻的收货信息以 JSON 或拼接字符串形式存进去。为什么这么做？因为你不能下单后修改地址导致订单信息变了，电商系统里订单必须保留下单时的状态，这是行业惯例。

2.2 商品分类与库存字段的设计细节

商品分类我用了 parent_id 做自关联，也就是无限级分类。一级分类比如“生鲜果蔬”，二级分类比如“新鲜蔬菜”“当季水果”。虽然网超系统一般两级就够用了，但设计成自关联之后，以后要加三级四级分类不用改表结构，直接在页面里维护父子关系就行。查询的时候用递归或者先一次性查出全部分类再在内存中组装成树形结构，返回给前端做级联选择器或者侧边栏菜单。

库存字段要特别注意：stock 在商品表里直接用整数表示，下单扣减库存时用 MyBatis 的乐观锁机制。我在 product 表里加了一个 version 字段，扣库存的 SQL 是：

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

stock >= #{quantity} 这个条件才是关键，用乐观锁机制防止了并发超卖。做课程设计可能你觉得不需要考虑并发，但我建议你在 SQL 层面加上这个条件，因为写上去之后答辩的时候可以解释“我考虑了并发场景下库存超卖的问题”，得分点直接拉满。另外我建议单独建一张 stock_record（库存流水表），每次扣减库存都记录一条流水，方便查账和对账。

3. 后端核心功能与 SpringBoot + MyBatis 实现

3.1 登录鉴权方案：JWT 还是 Session 拦截器

前后端分离的项目，登录鉴权是个绕不开的坎。我最终选的是 JWT（JSON Web Token）。原因很简单：不需要在后端存 session，服务器重启用户不用重新登录，前端拿到 token 存在 localStorage 里，每次请求在拦截器中带上 Authorization: Bearer <token> 头，后端通过拦截器校验。这种方式非常符合现在前后端分离开发的习惯。

后端拦截器我实现了一个 LoginInterceptor，继承 HandlerInterceptor 接口，在 preHandle 里取出 token、解析、放行或返回 401。这里要注意两个细节：第一个是放行路径问题，用户登录、注册、商品列表、商品详情这些接口必须放行，我在 WebMvcConfigurer 里配置拦截路径时把 /api/user/login、/api/user/register、/api/product/** 都加入 excludePathPatterns。第二个是管理员接口和用户接口要分开校验，我的做法是在拦截器里根据请求路径前缀 /api/admin/ 来区分角色，校验 token 里的 role 字段是不是 ADMIN。

密码存储千万不要用明文。我在项目里用了 BCrypt 加密，Spring Security 框架里有个 BCryptPasswordEncoder，可以单独引入使用。注册时加密，登录时用 matches 方法校验。每次用户注册的密码加密之后长得都不一样，哪怕两次密码相同，因为 BCrypt 内置了随机盐，安全级别足够。

3.2 购物车与订单流程实现时的设计重点

购物车这个功能看上去简单，就是一个表存 user_id、product_id、quantity，但实现的时候有几个细节非常影响体验。加入购物车时如果商品已经存在，不是插入新记录而是更新数量；购物车列表查询时要 JOIN 商品表把最新的商品名称、价格、主图查出来，页面上显示的应该是实时价格，而不是加入购物车那一刻的价格，所以购物车表里不需要存商品价格快照。还有个容易忽略的点是“商品是否下架或已删除”的状态，JOIN 商品表时默认只查 status = 1 的商品，否则用户购物车里会出现一个已删除的死数据。

订单流程我建议用状态机来设计，订单状态流转一定要清晰：待支付 -> 待发货 -> 待收货 -> 已完成，以及待支付超时可以关闭。用户下单的时候，后端要做的事情按顺序是：接收购物车里勾选的商品 id 列表，查询商品最新价格和库存，计算总金额，生成订单主表和明细表，删除已下单的购物车记录，扣减商品库存。这里有个“先扣库存还是先创建订单”的先后问题，我的做法是先扣库存、再创建订单。如果扣库存成功但订单创建失败，就回滚事务，库存自动恢复。SpringBoot 里用 @Transactional 注解即可搞定，这个注解是基于 AOP 实现的事务管理，任何 RuntimeException 都会触发回滚。

还有“锁库存”这个场景。为了避免多人同时下单导致超卖，我在扣减库存的 SQL 里加了 stock >= #{quantity} 条件，利用数据库行锁保证原子性，同时配合 MyBatis 的 update 返回值：如果返回 0，说明库存不够或者并发冲突，抛出异常让事务回滚。这个思路和真正电商系统的“预扣库存”理念是一致的，虽然是简化版，但逻辑完整。

3.3 MyBatis 缓存与分页查询的配置心得

MyBatis 的一级缓存默认是开启的，作用范围是同一个 SqlSession 内。在 Spring 整合环境下，每次请求都会新建 SqlSession，所以一级缓存基本只在同一个方法内的多次查询生效。我之前遇到过一个问题：同一个方法里先查商品列表，然后更新库存，再查商品列表，发现查出来的库存还是旧的，这就是一级缓存没被清掉。解决办法是在 Mapper 接口的更新方法上显式执行 sqlSession.clearCache() 或者在 XML 里设置 flushCache="true"，不过最稳妥的做法还是用 @CacheNamespace 自定义二级缓存时要注意缓存的失效策略。

二级缓存踩坑更严重，我一开始在 ProductMapper 上开启了二级缓存，但商品更新之后缓存没有及时清理，导致后台改了价格，前台一直显示旧价格。排查了半天才发现 MyBatis 的二级缓存是跨 SqlSession 的，默认的 flushInterval 是空，必须靠增删改操作自动清除缓存。但如果你在 XML 里写了关联表的 JOIN 查询，其他 Mapper 修改了关联表，当前 Mapper 的缓存是感知不到的，数据就会不一致。所以这类管理系统里，除非查询频率极高且数据变更频率极低，否则我建议不开二级缓存，复杂度大于收益。

分页查询我用的是 MyBatis 的 PageHelper，一个 PageHelper.startPage(pageNum, pageSize) 就能自动拦截 SQL 生成 limit 语句。但 PageHelper 有个我反复踩的坑：它会在你第一次执行查询时拦截，如果你 startPage 之后还想做别的操作再查询，分页就错乱了。所以下面这样写才是标准的：

java复制PageHelper.startPage(pageNum, pageSize);
List<ProductVO> list = productMapper.selectProductList(query);
PageInfo<ProductVO> pageInfo = new PageInfo<>(list);

startPage 尽量紧跟第一条查询语句。另外 PageHelper 生成的 count 查询在某些复杂 SQL 下会有性能问题，我看了一下它生成的 count SQL，一般是 SELECT count(0) FROM (原SQL) table_count，如果原 SQL 有 GROUP BY 或者 DISTINCT，count 可能不准确，此时我建议单独写一个 count 查询。

4. 前端 Vue 页面与交互实现

4.1 Vite 还是 Vue CLI，路由应该怎么设计

如果用的是 Vue3，我强烈建议直接用 Vite，启动速度快到起飞，配置也简单。Vue2 的老项目一般还停留在 Vue CLI 上，但新项目选 Vue3 + Vite 肯定是大方向。前端初始化时我用 Element Plus 作为 UI 组件库，和 Vue3 搭配最顺手，组件按需引入可以显著缩小打包体积。

路由设计上，我的做法是把用户端和管理员端分开。用户端路由嵌套一个 layout 组件，里面是侧边栏/顶栏/内容区，商品列表页、商品详情页、购物车页、订单列表页、结算页都在这个 layout 下。管理员端用独立的 admin layout，包含后台管理系统的那一套导航和内容区域。这样做的核心好处是：两个端布局完全不同，但你只需要在路由配置里做一次懒加载，不同角色进来的入口不同，互不干扰。

路由懒加载一定要用，component: () => import('@/views/product/ProductList.vue') 这种写法会在打包时自动分割出独立 chunk，首屏只加载当前需要的文件。我在开发中发现如果不做懒加载，首次打开页面加载 1MB 多的 JS，体验非常差，用懒加载后首屏基本能在 1 秒内出内容。

4.2 商品列表、购物车与订单页面的核心思路

商品列表页是网上超市的门面，我采用了 Element Plus 的 el-card 和栅格布局，一行展示四个商品卡片，每个卡片上包含商品图、名称、价格、销量、加入购物车按钮。商品数据通过 axios 请求后端 /api/product/list 接口，返回分页数据后用 el-pagination 做分页。搜索和分类筛选我通过 Vue Router 的 query 参数传递，比如 /product/list?categoryId=3&keyword=苹果，这样刷新页面后筛选条件不会丢失。

购物车页面我设计成一个弹窗侧边栏，而不是独立路由。因为购物车更偏向“快捷操作”场景，用户可能在商品列表页加购，看完购物车继续逛，用 el-drawer 组件从右侧滑出，体验很接近真实电商网站。购物车内每个商品可以修改数量、删除、勾选，选中的商品合计金额实时计算，用 Vuex/Pinia 维护购物车列表，这样即便在不同页面之间切换，数据也不会丢。这里有个关键设计：购物车的勾选状态也要存在 Vuex/Pinia 里，而不是组件的局部 data，因为结算页要读取用户勾选了哪些商品。

订单结算页把商品列表、收货地址、金额明细分成三块区域。收货地址是单选，默认选中 is_default = 1 的地址，切换地址时总金额不变，但运费可以按规则计算，比如满 99 包邮，否则运费 8 元。创建订单时需要把购物车里勾选的商品 id 传给后端，后端根据 id 查最新价格生成订单。有一个需要考虑的场景：用户在结算页停留太久，商品价格可能变了。我当时的做法是前端在结算页展示“价格以提交订单时为准”，后端真正以数据库为准重新算价，避免前端传价格导致用户可以篡改。

4.3 前后端接口对接时的细节问题

前后端分离开发最经典的问题就是跨域。SpringBoot 后端默认运行在 8080 端口，Vue 开发服务器运行在 5173 端口，两个端口不一致浏览器就会拦截跨域请求。我用了两种解决方式，开发环境中用 Vite 的代理配置，生产环境用后端配置 @CrossOrigin。建议核心用 Vite 代理：

js复制server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这样前端请求 /api/product/list 时，Vite 会帮你转发到后端 8080，浏览器看到的请求是同源的，开发体验最好。生产环境把前端 npm run build 后的 dist 目录丢到 Nginx，配置 /api 反向代理到后端服务即可。

axios 拦截器也很有必要统一封装。请求拦截器自动从 localStorage 获取 token，加到请求头；响应拦截器统一处理 401 跳转登录页、403 提示无权限、业务异常弹出 ElMessage。我见过很多同学在每个页面都 try-catch 处理错误，代码重复得想哭，用拦截器统一处理后，组件里只关心业务成功状态，清爽多了。

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

5.1 跨域、端口冲突与 MyBatis 映射失败

先说跨域，这是刚接触前后端分离最容易卡住的问题。如果没配代理，浏览器控制台会报 CORS policy 之类的错误，解决办法上面已经写了。但有个坑往往被忽略：后端配置 @CrossOrigin 时如果还同时配置了拦截器，拦截器先于 CORS 处理，可能会导致请求在拦截器里就挂了，没走到 CORS 的响应头设置上。我当时调跨域调到怀疑人生，后来发现是拦截器里 response 没写 Access-Control-Allow-Origin，解决办法是在拦截器里先处理 OPTIONS 请求，直接放行并加上跨域响应头。

端口冲突也很常见，SpringBoot 默认 8080 端口经常被其他进程占。Windows 下用 netstat -ano | findstr 8080 找到占用进程，然后用 taskkill /PID <pid> /F 强杀，或者直接在 application.yml 里改端口：server.port: 8081。Vite 的端口冲突系统会自动分配新端口，但和代理配置的 target 端口不一致的话，调你半天，所以建议用 server.strictPort: true 固定端口。

MyBatis 映射失败是新手重灾区。常见的现象是启动时报 Invalid bound statement (not found)，多半是 Mapper 接口和 XML 文件的 namespace 不对应，或者 XML 文件没放在 resources 目录对应路径下。我的习惯是：Mapper 接口放在 com.example.mapper，XML 文件放在 resources/mapper/ 目录下，并在 application.yml 里配置：

yaml复制mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.entity
  configuration:
    map-underscore-to-camel-case: true

map-underscore-to-camel-case 一定要开，否则数据库的 create_time 映射不到实体的 createTime 字段上，接口返回 null，前端就显示空白，排查起来非常隐蔽。

5.2 时间格式化、金额精度与排序问题

数据库时间和前端显示时间相差 8 小时，这个问题我印象太深了。MySQL 的 TIMESTAMP 类型默认使用数据库服务器时区，而 SpringBoot 默认时区是 UTC，导致查询出来的时间比北京时间慢 8 小时。解决办法是在 application.yml 里配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

同时 MySQL 连接串里也要加 serverTimezone=Asia/Shanghai，双保险。如果还不行，检查一下前端显示的字段类型是 Date 还是 String，有时候是 JSON 序列化的时候格式不对。

金额字段在 Java 里千万不要用 double，否则就会出现 0.1 + 0.2 = 0.30000000000000004 这种精度丢失问题。数据库用 DECIMAL(10,2)，Java 实体用 BigDecimal，计算总金额用 BigDecimal 的 add 方法而不是 +。为啥强调这个，因为我在用 double 计算订单金额时出现过 19.99 + 5.00 = 24.989999999999998 的奇葩结果，用户看到订单金额显示 24.98，直接社死。

排序问题主要是商品列表默认按销量或价格排序。MySQL 的 ORDER BY 在混合排序时容易出现排序结果不稳定，我的经验是在排序字段后面加一个唯一字段兜底，比如 ORDER BY sales DESC, id DESC，否则分页时可能出现同一商品出现在两页的问题。使用 MySQL 8.0 的同学还可以试试 ROW_NUMBER() 窗口函数，处理复杂的排名需求会很方便。

5.3 避坑指南：到哪都不吃亏的完整路径

有几个坑是我做了几轮项目才彻底想通的，这里整理一下，你在做的时候直接避开就好：

• 数据库表字段一定要有 create_time 和 update_time 两个字段，并且用 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP 自动维护。很多学生项目没有 update_time，后面排数据不一致问题排到崩溃。
• 所有字典类、枚举类的状态字段不要用字符串散着存，比如订单状态我看到有写“待付款”“待发货”“已删除”的，后来要统计就会发现 SQL 写得想死。正确做法是用数字枚举：0 待付款、1 待发货、2 待收货、3 已完成、4 已取消，前端做映射。这样 SQL 条件、统计都方便，数据量大的时候性能也更好。
• 删除操作不要物理删，而是逻辑删。商品表我加了个 status 字段，下架就是把 status 改成 0。订单取消同理，用 status 字段标识，不要在表里把记录删掉。这样既能保留操作痕迹，又避免了外键关联问题。
• 上传图片时，生产环境最好用云存储 OSS，课程设计可以用本地磁盘存储。本地存储要注意配置静态资源映射，SpringBoot 里需要重写 WebMvcConfigurer 的 addResourceHandlers 方法把 /upload/** 映射到实际磁盘路径，不然上传的图片永远 404。
• 接口返回格式要统一。我封装了一个 Result 类，包含 code、message、data 三个字段。成功返回 code=200，业务失败返回 code 非 200，前端只在 code === 200 时处理 data。这样写的好处是前端拦截器可以统一判断错误，不至于每个接口都要检查 response。

6. 从代码到部署：实战化的项目扩展思路

这套系统做完之后，如果你还有精力，我非常建议从下面几个方向去扩展，这也是我和多数面试官聊到这个项目时被问到的点。

第一个是 Redis 的使用。网上超市的热门商品列表、轮播图推荐位，这些数据查询频率高但更新频率低，非常适合用 Redis 做缓存。你只需要引入 spring-boot-starter-data-redis，在查询商品列表时先查缓存，缓存没有再去查数据库，然后回填缓存，设置过期时间。给商品详情页加 Redis 缓存后，接口响应时间体感能快好几倍。再进一步，可以用 Redis 的 zset 实现一个排行榜，展示销量最高的商品 Top10，这个是电商场景很常见的功能。

第二个是搜索引擎和全文检索。当商品数量上来之后，MySQL 的 LIKE %keyword% 查询性能会明显下降。你可以接入 Elasticsearch、或者轻量级的全文检索方案，把商品名称、描述、分类信息同步到索引中，搜索时走搜索服务而不是数据库。做这个扩展时，你会接触到数据同步（Canal 或者 MQ）、索引设计、搜索相关性这些知识点。

第三个是部署上线。如果项目只停留在本地跑，始终体会不到完整部署流程的坑。我的建议是：前端 build 后放到 Nginx，后端打成 jar 包用 systemd 或者 Docker 在服务器上运行，MySQL 数据库放到服务器。再配合域名、HTTPS 证书，整个项目就是一套真正可访问的“网上超市”了。第一次部署大概率会碰到启动失败、依赖缺失、数据库连接拒绝、端口被占用等一堆问题，这些排查过程本身就是提升经验的好机会。

第四个是微服务和容器化方向。如果走校招或者社招岗位对微服务有要求，可以把这个单体项目拆分成用户服务、商品服务、订单服务，服务之间用 OpenFeign 调用，再用 Nacos 做注册中心和配置中心，网关用 Spring Cloud Gateway。单体会话改成 token 后，服务间用 Redis 共享会话或让每个服务自行校验 JWT，这套思路和企业真实项目非常接近了。

这四个扩展方向做任何一个，都能让你在面试中从容地讲出“我是怎么一步步从单体优化演进”的心路。而且每个方向背后都有大量的知识点可以深挖，面试官顺着你聊的时候你也不怕没话说。

最后再分享一个小技巧：开发这类前后端分离项目时，建议先梳理“接口文档”再写代码，哪怕只是自己在 Markdown 里列出来，也能帮你理清字段和调用逻辑。我一开始跳过了这一步，结果后面前端等待接口的时候，因为字段名没对齐频繁返工。后面对照着接口规范开发，前端 mock 数据、后端并行开发，效率直线上升。这个习惯在我后来做任何项目时都用上了，确实受益良多。