SpringBoot电商商城系统设计与实战：从架构到部署全解析

1. 项目定位与功能全景

1.1 这个商城项目到底解决什么问题

网上商城系统可能是Java后端开发里被练手最多的项目类型，没有之一。不管是课程设计、毕业设计，还是刚入行想系统走一遍SpringBoot开发流程，商城项目几乎总在推荐列表前列。我见过太多人把这个项目做成一个纯粹的“增删改查演示”——代码能跑、页面能看，但要问起某个功能为什么这么设计、数据表为什么这么拆，就答不上来了。

这个基于Java+SpringBoot的网上商城系统，本质上是一个完整的电商业务闭环。它覆盖了从用户注册登录、商品浏览检索、购物车管理，到订单生成、库存扣减、后台商品管理、订单状态流转这一整条链路。和网上随处可见的“图书管理系统”“学生管理系统”相比，商城的业务复杂度和技术深度都高出不少，刚好适合用来检验你对SpringBoot、MyBatis、数据库设计、权限控制、缓存、异常处理这些核心知识点的掌握程度。

先说清楚这个项目适合谁。第一类是计算机专业应届生，需要一份能讲清楚、能动手演示的毕业设计；第二类是自学的Java新人，学了SpringBoot基础语法但没做过完整项目，需要一个能串联所有知识点的实战载体；第三类是转行做开发的同学，面试时需要一个拿得出手、能扛住追问的项目经历。不管你属于哪一类，这篇博文都会按“设计→实现→部署→排错”的顺序，把这个项目彻底讲透。

1.2 功能模块清单与优先级选择

做商城项目最容易犯的错就是一上来想全做：秒杀、优惠券、推荐算法、分布式锁、消息队列全往里堆。结果就是代码写了一万多行，bug也攒了一箩筐，最后哪一个功能都没讲清楚。按我个人的经验，第一版一定要做减法，把核心闭环跑通，再谈锦上添花。

最小可用版本至少要有这些模块：

• 用户端：注册、登录、商品分类浏览、商品搜索、商品详情、购物车、订单确认、下单、订单列表、订单详情
• 管理端：管理员登录、商品分类管理、商品管理（增删改查+上下架）、订单管理（发货/取消/查看详情）、用户管理
• 公共模块：统一异常处理、统一返回结构、分页查询、文件上传（商品图片）、拦截器或过滤器做登录校验

我见过很多人都纠结要不要做支付功能。我的建议是：第一版不要接真实支付，做个模拟支付就够了——用户点“去支付”，系统直接把订单状态从“待支付”改成“已支付”，同时打印一行日志。这样既跑通了订单状态流转的逻辑，又不会被微信/支付宝的商户资质、回调签名、证书配置卡住进度。

优先级排序也很重要。按依赖关系来排：先搭工程骨架和数据库结构，再做管理端的商品分类和商品管理（因为这部分没有太多前置依赖），然后做用户注册登录，接着是前台的商品展示和搜索，最后才是购物车和订单流程。订单是整条链路里最复杂的，放到最后做的时候，前面的基础模块已经验证过了，定位问题会容易很多。

1.3 项目附带物料的组织方式

这类项目的交付物通常包括源码、LW（论文/说明文档）、部署文档和讲解视频，它们各自有不同的定位，这里给你一个实用的组织思路。源码是整个项目的核心，建议用Git管理，目录划分要清晰：controller、service、mapper、entity、config、common、util这些包一个都不能乱。

LW文档的价值不在于“写得多”，而在于“说得清”。答辩的时候老师翻你的论文，重点看三件事：需求分析是否清楚、数据库设计是否合理、系统实现是否和设计对应得上。所以文档的重心应该放在用例图、ER图、核心表结构说明和关键流程描述上，代码块只贴最核心的片段，千万别把几十个类全贴进文档里。

部署文档是很多人容易忽略的一块。我不止一次见过学生把项目带过去演示的时候，因为MySQL版本不一致、JDK环境变量没配好、端口被占用这些问题当场翻车。部署文档里至少要写清楚：环境版本清单（JDK、Maven、MySQL、Node.js）、每个环节的安装步骤、配置修改位置、启动顺序、常见启动报错的解决办法。这篇文章后面会有一整节专门讲部署，你可以直接照搬。

2. 技术选型与架构设计思路

2.1 为什么SpringBoot能成为这类项目的主流选择

先回应一个知乎上隔三差五就被翻出来的问题：做商城，用SpringBoot还是SSH（Struts2+Spring+Hibernate）还是SSM（Spring+SpringMVC+MyBatis）？

SSH这套组合在2015年前后就已经基本退出主流视野了，Struts2的漏洞问题、Hibernate的复杂配置和性能调优难度，让它在中小型项目里非常吃亏。SSM虽然还能在一些老项目里见到，但它最大的痛点是“配置地狱”——Spring的XML配置、SpringMVC的组件扫描配置、MyBatis的mapper映射配置、数据源配置、事务配置，零零散散几十个XML和注解，每个都有坑。

SpringBoot的核心理念是“约定大于配置”。它通过自动配置机制，把Spring MVC、内置Tomcat、数据源、事务管理等常见基础设施的默认配置全部封装好，你只需要引入一个spring-boot-starter-web依赖，就能得到一个可运行的Web应用，连Tomcat都不用单独装。这就是为什么现在的企业项目和教学项目几乎一边倒地选择了SpringBoot。

从项目管理的角度说，SpringBoot还有一个隐性好处：它天然适合前后端分离的开发方式。后端只需要把自己的Controller写成RESTful接口，用JSON格式返回数据，前端用Vue或者React单独开发，两边约定好接口规范就能并行推进。商城项目做成前后端分离，不仅开发效率高，演示时也更能体现工程化能力。

2.2 整体分层架构与数据流向

这个商城的后端架构可以按下图来理解（这里用文字描述代替绘图）：

code复制Vue前端页面或Postman测试工具
        ↓ HTTP/JSON
Controller层（接收参数、校验、调用Service）
        ↓
Service层（业务逻辑、事务管理）
        ↓
Mapper层 / DAO层（数据持久化）
        ↓
MySQL数据库

分层的好处是职责清晰、可测试性强。Controller只负责“接客”，把HTTP请求参数解析出来，交给Service处理，然后把Service返回的结果封装成统一格式的JSON响应。Service层是核心，所有业务规则都在这一层实现，比如下单时校验库存、扣减库存、生成订单号和订单项，整个操作要加事务。Mapper层只做最简单的数据读写，不写复杂业务逻辑。

很多初学者会犯一个典型错误：把业务逻辑全堆在Controller里，结果一个方法几百行，既没法测试也没法复用。比如“下单”这个动作，Controller里就是接收用户ID、收货地址ID、购物车选中的商品ID列表，然后调用orderService.createOrder(...)，业务代码全在createOrder方法里。这样写的好处是，以后如果要做微信小程序端，只需要再写一套Controller，Service完全不用动。

统一返回结构也是容易被忽视但很重要的设计。我建议定义一个通用的返回体，大致长这样：

java复制public class Result<T> {
    private Integer code;   // 比如200成功、500失败，也可以自定义业务码
    private String message;
    private T data;

    public static <T> Result<T> success(T data) { ... }
    public static <T> Result<T> error(String message) { ... }
}

所有Controller的返回值都封装成Result<T>，前端拿到固定的结构，处理起来就非常统一。否则有的接口返回true，有的返回字符串，有的直接返回对象，前端那边能给你写出一堆分支判断来。

2.3 开发环境与工程结构

工程上我推荐先用start.spring.io生成基础骨架。这里直接列一套我自己验证过的版本组合，照着用基本不会踩坑：

项目内的包结构我习惯这样划分：

code复制com.example.mall
├── MallApplication.java          // 启动类
├── common/                       // 通用返回、全局异常、常量
├── config/                       // 配置类（拦截器、跨域、MyBatisPlus）
├── controller/                   // 接口层
├── entity/                       // 数据库实体类
├── mapper/                       // MyBatis接口
├── service/                      // 业务接口
│   └── impl/                     // 业务实现
├── util/                         // 工具类（JWT、MD5、日期等）
└── vo/                           // 视图对象（给前端传参用）

如果用的是前后端分离，前端单独建一个目录，Vue工程和后端工程互相独立。如果图省事，也可以用Thymeleaf做服务端渲染，但我的建议是别退回这条路——前后端分离写起来虽然工作量多一点，但接口设计、联调、部署这套流程才是真实企业项目的工作方式，对面试和履历都更有价值。

3. 数据库设计与核心表结构拆解

3.1 业务实体梳理与ER关系

数据库设计是商城项目的灵魂。很多人的项目最后被发现“只能演示、经不起答辩”，就是因为表结构设计得不够严谨。

先梳理业务实体：用户、分类、商品、购物车项、订单、订单项、收货地址、管理员。这些实体之间的关系是：

• 一个用户有多条收货地址（一对多）
• 一个分类下有多个商品（一对多）
• 一个用户有多个购物车项（一对多）
• 一个订单属于一个用户，包含多个订单项（一对多）
• 一个商品对应多个订单项，订单项里有下单时的快照价格

这里的核心难点是“订单项”这个表的设计。为什么不能只存一个订单表、里面用逗号拼商品名称和价格？因为你的订单提交之后，商品价格可能会变，商品可能被下架，如果订单只引用商品表的实时数据，那用户查看历史订单时看到的价格和当初付款时就会不一致。所以订单项必须把商品名、单价、商品图片这些关键字段冗余一份，形成快照。

3.2 核心建表SQL与字段注解

下面给一张核心的订单表设计，这个表是你项目里含金量最高的表之一：

sql复制CREATE TABLE `order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单号',
  `user_id` bigint(20) NOT NULL COMMENT '下单用户ID',
  `total_amount` decimal(10,2) NOT NULL COMMENT '商品总金额',
  `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '订单状态：0待付款 1已付款 2已发货 3已完成 4已取消',
  `receiver_name` varchar(50) NOT NULL COMMENT '收货人姓名',
  `receiver_phone` varchar(20) NOT NULL COMMENT '收货人电话',
  `receiver_address` varchar(255) NOT NULL COMMENT '收货地址',
  `remark` varchar(255) DEFAULT NULL COMMENT '买家备注',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

有几个细节需要留意。

第一个是订单号order_no，一定要加唯一索引，并且不能简单用数据库自增ID代替。原因有二：订单号需要展示给用户和物流系统，格式上通常做成时间戳+随机数或雪花ID；另外订单号在外人看来是业务规模的一个窗口，自增ID会暴露你平台的订单量。可以这样生成：yyyyMMddHHmmss + 4位随机数 + 用户ID后四位，基本上不会重复。

第二个是金额字段，一律用decimal(10,2)而不是float或double。浮点数在做金额运算时会出现精度丢失问题，这属于基础常识，面试也常问。

第三个是状态字段用tinyint枚举，而不是直接存字符串。数据库层面用数字简洁高效，具体含义在代码里用常量类或枚举类定义。

商品表相对简单，但要注意索引设计。商品名和标题字段建议加上普通索引，因为前台搜索的主要字段就是商品名。如果数据量大了还想优化，后续可以引入Elasticsearch，但那是进阶话题，第一版不必做。

3.3 数据一致性设计中的几个关键点

虽然单机MySQL事务能保证基本的ACID，但商城系统里依然有两个特别容易出问题的场景，这里提前说明。

第一个场景是“扣库存”。下单时要判断库存是否够，够了才扣减，然后生成订单。正确做法是：先查询库存，如果库存充足，执行UPDATE product SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}，然后根据受影响行数判断是否扣减成功。这一步不能先SELECT查到库存大于0后直接UPDATE，因为高并发下两个请求可能同时读到库存为1，然后都去扣减，导致超卖。用带条件的UPDATE语句让数据库来保证原子性，是单机部署下最简单有效的方案。

不过第一版项目里，如果只是做演示，并发量并不大，可以先用@Transactional把扣库存和创建订单包在同一个事务里，保证要么都成功、要么都失败。如果将来要应对双十一这种流量，就得引入Redis预扣库存、异步队列等方案，那是进阶话题，不在本文展开。

第二个场景是“重复下单”。用户在订单确认页面由于手抖或网络慢，连点了两次提交按钮，可能生成两笔重复订单。简单做法是在前端做提交按钮防抖，更稳的做法是后端校验——在事务里用用户ID加待支付状态的订单是否存在，或者用分布式锁/唯一索引防止并发重复提交。第一版用前端防抖加后端按用户维度加锁就够。

4. 核心功能模块的实现与关键代码

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

用户登录认证这块，传统的做法是用Session，前后端不分离的项目里非常常见。但既然选择了前后端分离，用JWT（JSON Web Token）会更合适。

JWT的原理不复杂：用户登录成功后，服务端生成一个包含用户ID、用户名等信息的Token，用密钥签名后返回给前端。前端把Token存在localStorage里，之后每次请求都在HTTP头的Authorization字段带上这个Token。服务端通过拦截器解析Token、验证签名，就能知道当前请求是谁发起的，无需在服务端保存会话状态。

核心实现大概是这样：

java复制@Component
public class JwtUtil {
    private static final String SECRET = "your-secret-key";
    private static final long EXPIRE = 7 * 24 * 60 * 60 * 1000L; // 7天有效期

    public String generateToken(Long userId, String username) {
        return Jwts.builder()
                .setSubject(username)
                .claim("userId", userId)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody();
    }
}

然后是拦截器，这里要处理两个问题：白名单放行和用户信息传递。注册、登录、商品列表、商品详情这些接口不需要登录就能访问，要把这些路径加入白名单；其他接口必须校验Token，校验通过后把用户ID放到ThreadLocal或请求参数里，方便Service层直接使用。Spring Boot的WebMvcConfigurer里可以这样注册拦截器：

java复制@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(jwtInterceptor)
            .addPathPatterns("/**")
            .excludePathPatterns("/user/login", "/user/register", "/product/**", "/category/**");
}

代码层面，具体的源码包里会包含完整的JwtInterceptor实现，这里需要提醒的是：密钥不要写死在代码里，应该配置在application.yml里；Token有效期不要太短，7天是个人实践中比较合适的值——太短用户频繁被踢下线体验极差，太长又有安全风险。

4.2 商品检索与缓存加速

商品模块看起来简单，无非是查表、分页、展示，但它是整个系统里和数据库打交道最频繁的部分。前台商城首页一打开，要加载分类树、推荐商品、新品上架，如果每次都直接查数据库，一旦数据量上来，数据库的压力会很明显。

第一版可以这样设计：商品列表接口用MyBatis-Plus的分页插件，按分类、关键词、价格区间、上下架状态做多条件组合查询。SQL用动态条件拼接，MyBatis-Plus的LambdaQueryWrapper就能很好解决，不需要手写动态SQL。下面给一个示例：

java复制public Page<Product> searchProducts(Integer categoryId, String keyword,
                                     BigDecimal minPrice, BigDecimal maxPrice,
                                     Integer pageNum, Integer pageSize) {
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    if (categoryId != null) {
        wrapper.eq(Product::getCategoryId, categoryId);
    }
    if (StringUtils.hasText(keyword)) {
        wrapper.like(Product::getName, keyword);
    }
    if (minPrice != null) {
        wrapper.ge(Product::getPrice, minPrice);
    }
    if (maxPrice != null) {
        wrapper.le(Product::getPrice, maxPrice);
    }
    wrapper.eq(Product::getStatus, 1); // 只查询上架商品
    wrapper.orderByDesc(Product::getCreateTime);
    return page(wrapper, pageNum, pageSize);
}

关于加缓存，我的建议是：第一版不要强行上Redis缓存商品列表。缓存引入了缓存一致性问题——数据库改了、缓存没更新，用户看到的还是旧数据。如果为了演示效果一定要加，可以只对“首页轮播图文案”“分类列表”这类不常变的数据做缓存。商品详情页可以加一个简单的Redis缓存，key为product:detail:{id}，后台修改商品时主动删掉对应缓存。

我在很多毕业设计项目里看到，学生把缓存写到所有查询方法上，结果后台改完商品名，页面上一整天才变，答辩时怎么演示都解释不清。这个坑一定要避开。

4.3 购物车与订单完整流程

购物车表的设计有讲究。我建议用一张cart_item表，字段包括id、user_id、product_id、quantity、selected（是否选中）、create_time、update_time。这个方案把购物车的状态持久化到数据库，用户在不同设备上登录，购物车数据都是同步的。有些项目把购物车存在浏览器localStorage里，好处是省数据库压力，但切换设备就没数据了，而且无法支持后台数据分析。作为毕设项目，入库是更稳妥的选择。

购物车接口就四个：添加商品、修改数量、删除条目、查询列表。每个接口都从JWT里取当前用户ID，然后操作这张表。有个小细节是“添加商品”时，如果商品已经在购物车里，应该数量累加而不是新插一条记录。

订单流程是整个系统的核心，步骤拆开是这样的：

1. 用户从购物车选择已勾选商品，点击“去结算”
2. 进入订单确认页，展示商品清单、选择收货地址、填写备注
3. 提交订单，后端执行：校验库存 → 生成订单主表记录 → 生成订单项记录 → 扣减库存 → 清空购物车对应条目
4. 返回订单号，前端跳转到“订单支付”页
5. 点击模拟支付 → 订单状态改为已付款

事务的写法要注意，整个步骤3必须包在一个@Transactional里，任何一个环节失败都要全部回滚，否则就会库存扣了但订单没生成，或者订单生成了但购物车没清干净。

还有一个财务上的小坑：计算订单总金额时，后端要重新查一次数据库里的商品价格来计算，不能信任前端传过来的金额。用户在前端页面把价格改成1分钱然后提交，如果后端不做校验直接用前端金额，这单就亏大了。金额以数据库为准，这是电商系统的底线。

4.4 后台管理模块实现要点

后台管理端我建议独立做一套，和前台分开。一般后台管理系统用Vue + ElementUI搭建，前端工程单独维护，功能上覆盖管理员登录、商品管理、分类管理、订单管理、用户管理。

商品管理的核心是图片上传。本地开发时，上传的图片直接保存到服务器的某个目录，然后配置一个静态资源映射，让图片可以通过URL访问。Spring Boot里这样配置：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/");
    }
}

这样前端上传图片后，后端返回/upload/xxx.jpg的地址，前端<img>标签直接引用即可。生产环境如果上了云服务器，也可以用OSS对象存储，但本地项目没必要。

订单管理是后台的核心功能，常见操作是查看订单列表、按状态筛选、发货（修改订单状态为已发货）、取消订单。这里注意一点：取消订单要恢复库存。用户在待支付状态下取消订单，商品库存要加回去，这个逻辑别漏掉。

管理端的权限控制可以简单点，登录时把管理员和普通用户区分开，管理员接口加一个角色校验过滤即可。如果要做得更完善，可以用Spring Security + JWT实现细粒度权限，但那会大大增加复杂度，没有充分准备前不建议碰。

5. 部署运行与工程落地

5.1 本地环境准备：从零开始跑起来

很多项目的部署文档写得像天书，动不动就是“配置好环境即可”，但实际对新手来说，最卡壳的就是环境配置。下面按步骤走一遍，照着操作就不会有问题。

第一步是JDK。现在很多电脑上装的是JDK 17甚至21，但企业项目、教学项目甚至很多老框架都还是以JDK 8为主。如果你在启动项目时遇到奇怪的依赖报错，先把JDK版本切回8或11。JDK的环境变量配置是：新建JAVA_HOME，指向JDK安装目录，然后在Path里追加%JAVA_HOME%\bin，最后命令行里输入java -version和javac -version看看是否生效。

第二步是Maven。Maven的settings.xml里最好配置阿里云镜像仓库，否则依赖下载速度会慢到怀疑人生。镜像配置网上有大把，这里不重复，但我的心得是：如果遇到依赖下载一半失败，先删掉本地仓库repository目录下的对应包，再执行mvn clean install -DskipTests重新下载。

第三步是MySQL。推荐直接用压缩版安装，初始化数据目录后修改root密码，然后创建一个专用数据库。注意Spring Boot的数据库连接URL要加时区参数，8.0的MySQL如果不写serverTimezone=Asia/Shanghai会报错。

5.2 后端打包与启动

本地开发时直接用mvn spring-boot:run或IDEA里右键运行启动类即可。但演示和部署时，需要打成可执行的Jar包：

bash复制mvn clean package -DskipTests

打包完成后，在target目录下会生成一个xxx.jar文件，用以下命令启动：

bash复制java -jar mall-0.0.1-SNAPSHOT.jar

如果服务器内存不大，可以限制JVM的内存占用：

bash复制java -Xms256m -Xmx512m -jar mall-0.0.1-SNAPSHOT.jar

后台运行可以借助nohup命令，或者写一个简单的、使用systemctl管理的服务脚本。每次部署前，把旧进程杀干净再启动新的，避免端口占用：

bash复制netstat -tlnp | grep 8080
kill -9 <pid>

启动日志里看到Started MallApplication in x.xxx seconds就说明启动成功了。如果用的是云服务器，记得在安全组里放行8080端口，否则外网访问不了。

5.3 部署文档里最容易忽视的10个细节

整理一份部署自查清单，帮你避开我见过的各种坑：

1. MySQL服务是否启动，命令行mysql -u root -p能不能连上
2. 数据库编码是否用了utf8mb4，商品的emoji字符在utf8下会报错
3. application.yml里的数据库账号密码、URL时区是否正确
4. JDK版本是否符合项目要求，java -version确认
5. Maven仓库有没有配好镜像，依赖能不能拉下来
6. 前端如果是单独的Vue工程，是否执行了npm install和npm run build，并且正确配了后端接口地址
7. 前端打包后的静态文件，是用Nginx托管，还是直接丢进SpringBoot的static目录
8. 文件上传的目录是否存在，权限是否可写
9. 8080端口是否被占用，或被防火墙拦截
10. 配置文件里的密钥、密码在真实环境里有没有改成自己的，别把教程里的默认值原样带上去

每次部署完，按这个清单过一遍，基本能避免90%的问题。

6. 常见问题与调试实录

6.1 启动阶段的高频报错

java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

这个报错在JDK 9以上版本特别常见，因为JDK 11把JAXB模块移除了。解决办法是手动引入依赖，或者直接把JDK切回8。坦白说，SpringBoot 2.x配合JDK 8是最省心的组合，没有之一。

Access denied for user 'root'@'localhost' (using password: YES)

不是密码错了就是权限不对。先确认application.yml里的用户名密码，再确认MySQL里该用户是否允许从当前主机连接。

Whitelabel Error Page，控制台没有明显报错

这是后台接口抛了异常但前端页面没拿到正常状态码。典型的场景是接口路径写错、请求方式不匹配、参数类型转换失败。建议后端加上全局异常处理器，把异常信息返回给前端，同时查看控制台完整堆栈，别只看Tomcat的默认错误页。

Port 8080 was already in use

端口被占用，终极解决办法是换端口或杀掉占用进程：

bash复制netstat -aon | findstr :8080
taskkill /F /PID <pid>

6.2 数据与事务相关的坑

OutOfMemoryError: insufficient memory

记得上次看到一个热词就是这个，在本地调试时如果启用了IDEA的多个高内存插件，极易触发。解决办法是调大JVM堆内存，在启动配置里加-Xmx1024m。

前端传过来的日期格式和MySQL不一致

LocalDateTime类型在SpringBoot默认序列化格式是yyyy-MM-dd'T'HH:mm:ss，但前端表单往往是空格分隔。在application.yml里加统一的JSON序列化配置：

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

@Transactional失效

常见原因是调用了同类内部方法，Spring的AOP代理没生效。比如OrderServiceImpl.orderCreate()调用了同类的deductStock()，后者的@Transactional就不生效。这种情况要么拆到另一个Service，要么自己注入自身的代理对象。

批量插入数据时主键重复

MyBatis-Plus的saveBatch默认走了复合主键策略，如果表中主键是AUTO_INCREMENT，要确保实体主键的IdType注解是AUTO。否则默认的雪花ID会让自增主键完全错乱。

6.3 缓存一致性与并发场景的调试心得

我在自己的项目里对缓存踩过一个非常典型的坑。最初我在商品详情接口上加了Redis缓存，后台管理员改商品价格后，前台的详情页还是旧价格。排查了半天发现，问题出在后台管理的更新接口只更新了数据库，根本没有删除对应的Redis key。后来我把所有写操作里都加上“更新数据库后删除缓存”的逻辑，一致性才恢复正常。如果你们用的也是Redis，建议在application.yml里设置一个统一的前缀，比如mall:product:detail:，这样排查缓存问题时，redis-cli keys "mall:*"一条命令就能列出所有相关key。

并发场景下还有一个经典情况：下单时库存扣减用UPDATE ... WHERE stock >= #{count}，如果受影响行数为0，说明库存不足，直接抛异常回滚。这个方案在单库单表下是稳定的，也不需要额外引入Redis分布式锁。

最后建议，把SpringBoot的单元测试用起来，这也是很多人忽略的技能点。就算只测试一下Service层的基础CRUD，对你的代码质量也是很大的提升，而且面试和文档里提到“编写了单元测试”会比空口说“我做过项目”更有说服力。

这个项目如果只是照着走一遍代码，那它对你而言就是一个“复现品”；但如果你把每一张表的设计原因、每个接口的事务边界、每个配置项的含义都搞清楚，它就成了一个绝佳的面试武器。我在实际做这类项目时，最大的体会是：一个项目能帮你拿到工作offer，靠的往往不是功能数量，而是你能不能用通顺的逻辑，把每一个设计决策讲明白。希望你在这个商城里学到的，不只是跑通代码而已。