Java网上商城源码精讲：SpringBoot+MyBatis+Redis全链路

简介：这是面向 Java 初学者的网上商城项目完整源码包，适合课程设计、毕业设计或电商开发入门实践，覆盖从页面展示到后台处理的常见商城业务。项目基于 JSP、Servlet 和 JavaBean 编写，包含用户注册登录、商品分类展示、购物车、订单管理、留言反馈等模块，并附带 SQL 数据库脚本，便于快速建表并导入初始数据。压缩包共 262 个文件，约 27.19MB，其中 JSP 页面用于前台展示与交互，Java 源文件承担核心逻辑，class 文件为编译结果，SQL 脚本用于初始化数据库，其余 JS、CSS 资源负责前端效果，jpg 图片则为商品图等静态素材。已有 553 人学习下载，目录按功能拆分，便于查找。通过源码可理解 Servlet 请求分发、业务层封装、数据库访问及页面传参的完整链路，也适合在此基础上扩展支付、后台管理等功能，提升项目二次开发能力。

1. 项目定位：这份 Java 网上商城源代码，从登录到下单全链路可用

刚拿到这套 Java 网上商城源代码时，我第一反应不是打开 IDE，而是先翻 README 和数据库脚本。一个商城项目最怕的不是功能少，而是逻辑链断裂——商品加进购物车了，下单却报库存不足；后台改了价格，前台还是旧数据。这套项目恰好把商品、购物车、订单、支付回调、后台管理整条串起来了，用的是 Spring Boot + MyBatis + MySQL + Redis 的经典单体组合，前端走 JSP + Bootstrap，属于那种「能跑通、能看懂、能二次开发」的 Java 项目。如果你是准备做毕业设计、想学电商业务闭环，或者打算在成熟骨架上改出自己的商城，这份源代码都值得你下载下来，先跑通再动手改。

2. 架构与目录：先摸清这个 Spring Boot 单体的家底

拿到源码第一件事永远是看结构，而不是急着启动。这个网上商城是一个标准的 Spring Boot 单体应用，前后端不分离，服务层拆得比较清楚。看懂目录结构，后面改代码时才知道去哪儿找类。

2.1 技术选型：为什么是 Spring Boot + MyBatis + Redis 的组合

这套项目没有用微服务那套复杂东西，老老实实走单体。Spring Boot 负责启动和自动配置，MyBatis 管 SQL 层，MySQL 存业务数据，Redis 扛缓存和购物车，前端是 JSP 页面加少量 Bootstrap 样式。对于商城这种业务密集型的系统，单体反而比微服务好维护：事务好控制、部署只需要一个 jar、调试时不用跨服务追链路。

Redis 在这个项目里占了两个关键位置：一个是商品详情的缓存，另一个是购物车。购物车用 Redis 的 Hash 结构存，key 是用户 id，field 是商品 id，value 是选中数量。这个设计的好处是用户登录态一过期，购物车还能从 Redis 里捞回来，不会像 Session 购物车那样说没就没。

2.2 目录结构与包职责

项目解压后根目录就是 Maven 标准布局，src/main/java下按业务模块分包，src/main/resources里放着 application.yml、Mapper XML 和 SQL 脚本。整体看下来，模块边界切得比较清楚，没有那种所有 Service 挤在一个包里的情况。

src/main/java ├── controller # 控制层，商品/购物车/订单/用户/后台管理 ├── service # 接口层，定义业务方法 │ └── impl # 实现类，核心逻辑都在这里 ├── mapper # MyBatis 的 Mapper 接口 ├── entity # 数据库实体类 ├── vo # 视图对象，给前端页面用的封装 ├── interceptor # 登录拦截器、管理员拦截器 ├── config # Redis 配置、WebMvc 配置 └── common # 统一返回结果、异常处理

resources 下面有几个东西值得注意：sql/目录里是整个数据库的初始化脚本，mapper/目录对应每个 Mapper 接口的 XML 文件，JSP 页面在src/main/webapp/WEB-INF/jsp下按页面模块分成goods、cart、order、user等子目录。找页面的时候按模块找，比全堆在一个文件夹里省事得多。

2.3 数据库表设计：订单、商品、用户的关系怎么拉

数据库脚本一共建了 8 张表左右，核心的是用户表、商品表、购物车表、订单表和订单明细表。订单和订单明细是一对多关系。

订单表那条order_no字段是典型的雪花算法生成的长 ID，前端展示、支付回调、对账都以它为准。商品表里的stock字段在下单时会做扣减，如果扣成负数，事务就会回滚，这个逻辑后面拆代码时会细讲。

3. 核心模块拆解：一个请求从进入到返回的完整链路

商城最核心的一条链路是：用户登录 → 浏览商品 → 加购物车 → 下单 → 扣库存。这一章把每个环节的关键代码拎出来讲，你改代码时能直接对着抄。

3.1 登录鉴权：拦截器把未登录用户挡在门外

登录用的是 Session 方案，登录成功后在 session 里放一个user对象。所有需要登录的接口都通过一个自定义拦截器做校验。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); if (session.getAttribute("user") == null) { // 未登录用户跳转到登录页，携带目标地址用于登录后跳回 String uri = request.getRequestURI(); String query = request.getQueryString(); String target = query == null ? uri : uri + "?" + query; response.sendRedirect("/login?target=" + URLEncoder.encode(target, "UTF-8")); return false; } return true; } }

这段代码的逻辑很直白：preHandle里取 session 中的user属性，没有就重定向到登录页，并把当前请求路径拼到target参数里。登录成功之后，控制器会从target参数里取出原地址再跳回去，用户体验是“我刚点的是购物车，登录完还是落到购物车”。

拦截器注册在 WebMvc 配置类里，要注意登录接口本身必须排除掉，否则会形成死循环重定向。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/goods/**", "/css/**", "/js/**", "/images/**"); } }

/goods/**是商品浏览路径，游客允许直接看，所以排除掉；静态资源如果不排除，页面会加载不出来，这个坑后面避坑章还会提到。改的时候如果你想放开某个新接口的匿名访问，记得往 excludePathPatterns 里加，这是最简单也最容易漏的一步。

3.2 商品列表与详情：分页查询加 Redis 缓存

商品列表走的是 MyBatis 分页查询，控制器接收pageNum和pageSize，用一个统一的PageResult封装返回给页面。详情页则加了 Redis 缓存，同一个商品被反复浏览时不会每次都打 MySQL。

@Service public class GoodsServiceImpl implements GoodsService { @Autowired private GoodsMapper goodsMapper; @Autowired private StringRedisTemplate redisTemplate; private static final String GOODS_KEY_PREFIX = "goods:detail:"; @Override public GoodsVO getDetail(Long goodsId) { String key = GOODS_KEY_PREFIX + goodsId; String json = redisTemplate.opsForValue().get(key); if (json != null) { return JSON.parseObject(json, GoodsVO.class); } GoodsVO goods = goodsMapper.selectDetail(goodsId); if (goods != null) { redisTemplate.opsForValue().set(key, JSON.toJSONString(goods), 30, TimeUnit.MINUTES); } return goods; } }

这里有个细节：缓存里存的是GoodsVO而不是Goods实体。因为页面需要展示的分类名、卖家昵称等字段在实体表里没有，直接用实体序列化会丢字段。数据一致性上用了最简单的缓存过期策略，30 分钟过期，后台改价后最多 30 分钟生效。想做实时一致的话可以改成“更新商品时主动删缓存”，但那就需要改后台管理的更新逻辑了。

商品列表的分页查询是纯 MyBatis 做的，XML 里写动态 SQL，搜索关键字、分类筛选都是拼条件：

<select id="selectPage" resultType="com.example.mall.vo.GoodsVO"> SELECT g.*, c.category_name FROM goods g LEFT JOIN category c ON g.category_id = c.id <where> <if test="keyword != null and keyword != ''"> AND g.goods_name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND g.category_id = #{categoryId} </if> </where> ORDER BY g.id DESC </select>

<where>标签会自动去掉第一个多余 AND，<if>判断参数是否为空。这种写法是 MyBatis 动态 SQL 的常规操作，二次开发加筛选条件时照着这个格式再加一个<if>就行。

3.3 购物车：Redis Hash 结构存取，不丢数据

购物车是这个项目里比较出彩的一块。它没有把数据全塞进 Session，而是用 Redis 的 Hash 做了一层，键是用户 ID，字段是商品 ID，值是一个 JSON 字符串，包含商品名、单价、数量。

@Override public boolean addToCart(Long userId, Long goodsId, Integer count) { String key = "cart:" + userId; String field = String.valueOf(goodsId); GoodsVO goods = goodsService.getDetail(goodsId); if (goods == null || goods.getStock() < count) { return false; } CartItem cartItem = new CartItem(); cartItem.setGoodsId(goodsId); cartItem.setGoodsName(goods.getGoodsName()); cartItem.setPrice(goods.getGoodsPrice()); cartItem.setCount(count); cartItem.setStock(goods.getStock()); // 如果购物车已存在该商品，数量累加 String oldJson = redisTemplate.opsForHash().get(key, field); if (oldJson != null) { CartItem oldItem = JSON.parseObject(oldJson, CartItem.class); cartItem.setCount(oldItem.getCount() + count); } redisTemplate.opsForHash().put(key, field, JSON.toJSONString(cartItem)); return true; }

这个设计的优势在于：用户下单失败或者退出重新登录，购物车数据还在 Redis 里，不需要通过数据库购物车表反复读写。后端结算页拉取购物车时直接redisTemplate.opsForHash().entries(key)一次拿全量，再按商品 ID 批量回源查最新价格，避免用户看到的是加购时的旧价。

一个我建议留意的点：这里加购时校验了库存，但库存是实时查的。并发高的时候这个校验会有竞态，两个请求同时加购同一商品，最后可能超出库存。生产级做法是加购不校验、下单时用库存扣减事务兜底，这套代码里把校验放在加购是为了用户体验提前感知，属于取舍，算不上 bug。

3.4 订单与库存扣减：事务 + 行级锁

下单是整个项目里对事务要求最高的地方。用户点“提交订单”后，后端要同时做三件事：生成订单主表和明细、扣减商品库存、清空购物车。这三件事要么全成功要么全失败，用@Transactional一把梭。

@Transactional(rollbackFor = Exception.class) @Override public OrderVO createOrder(Long userId, Long[] cartIds) { // 1. 根据 cartIds 读取购物车中选中的商品 List<CartItem> items = cartService.getSelectedItems(userId, cartIds); if (items == null || items.isEmpty()) { throw new RuntimeException("购物车为空"); } // 2. 生成订单号并计算总价 String orderNo = String.valueOf(IdWorker.getId()); BigDecimal totalPrice = BigDecimal.ZERO; for (CartItem item : items) { totalPrice = totalPrice.add(item.getPrice().multiply(new BigDecimal(item.getCount()))); } Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setTotalPrice(totalPrice); order.setPayStatus(0); // 0 未支付 orderMapper.insert(order); // 3. 扣库存，逐条更新，stock > 0 保证数据一致 for (CartItem item : items) { int rows = goodsMapper.deductStock(item.getGoodsId(), item.getCount()); if (rows == 0) { throw new RuntimeException("商品库存不足: " + item.getGoodsName()); } // 写订单明细 OrderDetail detail = new OrderDetail(); detail.setOrderId(order.getId()); detail.setGoodsId(item.getGoodsId()); detail.setGoodsPrice(item.getPrice()); detail.setGoodsCount(item.getCount()); orderDetailMapper.insert(detail); } // 4. 清空已下单的购物车项 cartService.removeItems(userId, cartIds); return orderService.wrapOrderVO(order); }

扣库存的 SQL 是重点，它用了条件更新来避免超卖：

UPDATE goods SET stock = stock - #{count} WHERE id = #{goodsId} AND stock >= #{count}

这条 SQL 的返回值rows是受影响行数。如果库存不够，stock >= #{count}条件不成立，更新 0 行，rows == 0就抛出异常，整个事务回滚，订单、明细、库存全部撤销。这是典型的“乐观库存扣减”，比先查再改安全得多，也是这套项目里最值得学的写法之一。

4. 本地运行：从 JDK 到浏览器，四步跑起来

我试过在全新环境把项目从零跑通，整个过程最耗时间的其实是环境细节。按下面的步骤走，半小时内应该能在浏览器看到首页。

4.1 环境准备：JDK、Maven、MySQL、Redis 一版到位

JDK 12 或 12 以下版本。项目基于 Spring Boot 2.x 开发，用 JDK 17 会有 javax 包缺失的问题，必须降级或者加依赖兼容。Maven 3.6 以上，IDEA 自带的也行。MySQL建议 5.7 或 8.0，Redis 建议 5.0 以上版本。

装 MySQL 和 Redis 的时候注意：MySQL 如果是 8.0，驱动要匹配com.mysql.cj.jdbc.Driver，而且连接串里必须加上serverTimezone=Asia/Shanghai，否则启动报时区错误；Redis 默认端口 6379，windows 版本直接双击 redis-server.exe 就能起，Linux 用systemctl start redis。

4.2 初始化数据库：执行 SQL 脚本而不是手动建表

项目里sql/mall.sql是完整的建库建表语句，包含测试数据。用 Navicat 或命令行执行：

mysql -uroot -p < sql/mall.sql

执行完检查一下goods表里有没有数据，商城首页是依赖这些种子数据的。我习惯用命令行导，因为在 IDEA 里执行有时会因为 SQL 里包含DELIMITER存储过程被 Visual Studio Code 的客户端搞出编码问题，命令行最稳。

4.3 修改配置：数据库密码和 Redis 连接

打开src/main/resources/application.yml，找到数据源配置：

spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379

把password改成你自己的数据库密码。注意useSSL=false一定保留，本地环境没有 SSL 证书配 true 会连不上。Redis 如果没有设密码，password 字段就留空或者不写，Redis 配置缺少时 Spring Boot 会自动用默认空密码连接。

serverTimezone=Asia/Shanghai这个参数是真后悔药，不加它，MySQL 8 的驱动会报The server time zone value 'Öйú±ê׼ʱ¼ä'这一类乱码时区错误，本质是连接参数缺了时区声明，加上就好。

4.4 启动项目：两种方式，推荐第二种

第一种，在 IDEA 里找到MallApplication.java，右键 Run。第二种，用 Maven 打包再跑 jar，这种方式更贴近生产，也便于排查启动问题：

mvn clean package -DskipTests java -jar target/mall-0.0.1-SNAPSHOT.jar

看到日志里出现Tomcat started on port(s): 8080就说明启动成功了。浏览器访问http://localhost:8080/，首页能出商品列表就是跑通了。测试账号一般在 SQL 脚本里埋了，查一下user表，用里面的用户名密码登录，如果不想查可以直接用注册接口新注册一个。

启动失败的排查顺序是：先看端口占用，netstat -ano | findstr 8080找出占用进程杀掉；再看数据库连接日志，报Access denied就是密码错了；最后看 MyBatis 的 mapper 扫描路径，报Invalid bound statement就是 XML 没被编译到 classes 目录，清理 Maven 缓存重新mvn package一下。

5. 避坑清单：数据库、Redis、静态资源配置的踩坑记录

这个项目我在三种不同环境跑过：Windows 本地、Linux 服务器、还有 Docker 容器。每个环境都有各自的坑，挑典型的几条写出来，你大概率也会撞上。

5.1 数据库时区与驱动不匹配导致的启动失败

现象：java -jar启动时抛出Cannot create PoolableConnectionFactory，Caused by 指向The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。

原因：MySQL 8.x 的 JDBC 驱动要求连接串里显式声明时区，不声明就用服务器默认时区，而默认时区通常是系统时区缩写，驱动不识别。网上很多教程照抄老项目的连接串，漏了serverTimezone，于是翻车。

解决：在application.yml的 url 末尾加上serverTimezone=Asia/Shanghai。另外检查驱动版本，pom 里mysql-connector-java用 8.0.x 的话，driver-class-name必须是com.mysql.cj.jdbc.Driver，老版本com.mysql.jdbc.Driver会继续报错。

5.2 Redis 反序列化异常：默认 JDK 序列化导致乱码

现象：登录后浏览商品详情，控制台报java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String。

原因：项目里StringRedisTemplate和RedisTemplate混用了。有些注入的地方用的是RedisTemplate<String, Object>，它默认用 JDK 序列化，存进 Redis 的 key 带了\xac\xed\x00\x05t\x00前缀，肉眼看着是乱码，读取时类型也对不上。商品详情是可空判断，缓存命中时直接JSON.parseObject解析失败。

解决：统一用StringRedisTemplate操作 Redis，存取值都转成 JSON 字符串。如果项目里确实有RedisTemplate<String, Object>的注入点，在配置类里显式设置StringRedisSerializer：

@Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setHashKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new Jackson2JsonRedisSerializer<>(Object.class)); template.afterPropertiesSet(); return template; }

改完把 Redis 里之前存的乱码 key 清一遍，用redis-cli flushdb或者keys "goods:*"找到后删掉，不然同样的 key 还存在旧序列化数据，照样报类型转换异常。这个坑最隐蔽的地方在于：清缓存前每请求报错一次，清完就好，很多人以为是代码逻辑问题，其实是被脏数据卡住了。

5.3 前端页面样式丢失或者 404

现象：首页能打开，但 CSS、图片全部加载不出来，F12 看到一堆Failed to load resource: the server responded with a status of 404。

原因：拦截器把/css/**、/js/**、/images/**拦截了。排查时发现WebConfig里的excludePathPatterns写的是/static/**，但 JSP 里资源路径写的是/css/style.css，实际访问路径不包含/static前缀，所以全被拦住了。

解决：把拦截器排除路径改成与页面资源路径一致，/css/**、/js/**、/images/**都加进去。另外检查 Spring Boot 静态资源映射，默认静态资源目录是classpath:/static/，JSP 页面里<link href="/css/style.css">对应src/main/resources/static/css/style.css，别在 webapp 下重复建一个 css 目录，那不仅不会生效，还会造成路径歧义。

5.4 打包后 Mapper XML 没有进入 jar

现象：本地 IDEA 启动一切正常，mvn clean package后丢到服务器跑，接口报Invalid bound statement (not found): com.example.mall.mapper.GoodsMapper.selectPage。

原因：Maven 默认只打包src/main/resources下的文件，如果 Mapper XML 放在src/main/java的 mapper 包目录下，编译时不会复制到 classes 里去。IDEA 里跑的时候依赖的是编译器的资源复制行为，所以本地没事，一打包就缺文件。

解决：在pom.xml的 build 里显式声明资源目录：

<build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> <resource> <directory>src/main/resources</directory> </resource> </resources> </build>

这是典型的“本地没毛病，一部署就翻车”案例，血泪经验。以后每次打完包，先jar tf target/mall.jar | grep mapper确认 XML 在不在，再往服务器上扔。

6. 二次开发：把商城改成你自己的版本

跑通只是第一步，上手改才是这份源码的价值所在。我挑三个最常见、性价比最高的改造点讲，每个都给出具体的切入位置和验证方式。

改造点一：购物车从“存全量”改为“存 ID，结算时回源”。现在的购物车项把商品名、单价都冗余存进 Redis，这会导致后台改价后用户购物车里的价格还是旧价。改动很简单，加购时只存商品 ID 和数量，结算时拿所有商品 ID 批量查数据库组装数据。切入位置是CartServiceImpl的getSelectedItems方法，把从 Redis 解析全量 JSON 改成按 ID 批量查goodsMapper.selectByIds。验证方式是：后台把商品价格从 100 改成 80，已加购物车的用户刷新结算页，看到的价格变为 80。

改造点二：订单超时未支付自动关单。商城系统里用户下单不付钱是常态，现在订单表只有pay_status，没有超时机制。建议加一个expire_time字段，下单时设置为当前时间加 30 分钟，再写一个定时任务每分钟扫一次，把pay_status=0且expire_time < now()的订单改成已关闭，同时回补库存。切入位置是OrderServiceImpl的createOrder方法，和新增一个OrderCloseTask定时任务类。

@Component public class OrderCloseTask { @Scheduled(cron = "0 * * * * ?") public void closeExpiredOrders() { // 1. 查询超时未支付订单 // 2. 遍历订单，更新状态为已关闭 // 3. 对每个订单明细，调用 goodsMapper.recoverStock } }

验证方式：下单后把expire_time改成 1 分钟前，等定时任务跑一次，看订单状态变更为已关闭且库存回补，用户再次下单同商品库存数正常。

改造点三：支付回调的幂等处理。项目里的支付是模拟的，点“支付”直接改状态。如果你要接真实支付，回调接口必须做幂等：同一个订单可能收到多次回调。建议在数据库order表加一个pay_notify_status字段，回调处理前先UPDATE order SET pay_notify_status=1 WHERE order_no=? AND pay_notify_status=0，受影响行数为 0 说明已处理过，直接返回成功。这个写法跟库存扣减是同一种思路，用条件更新防重。

改完代码后，回归测试的顺序是从登录到下单全链路走一遍，然后手动改数据库模拟各种边界情况。我从这个项目里学到的最大教训是：商城这种系统，永远不要相信前端传入的价格，所有金额计算必须后端根据数据库实时数据来算。从那以后我每次改这类项目，都会强制把接口入参里的价格字段全部换成 ID，再在 Service 层回源查库，宁可多一次查询，不给刷单留一丝机会。希望跑通这套源码的经历，也能帮你少踩几个坑。

本文还有配套的精品资源，点击获取