企业官网建设流程全解析

做过不少Java Web项目之后，我得坦白说，第一眼看到"基于Java springboot滁州市特产销售商城系统"这个题目，脑子里冒出来的念头是：这不就是最常见的B2C电商商城嘛，没有分布式、没有秒杀、没有高并发压测，看起来就是个毕设/课设水平的CRUD系统。可真当我把需求拆开、把代码一行行过完才发现，"典型"两个字恰恰是最考验基本功的地方——从数据库设计、订单状态机，到登录鉴权、文件上传、Redis缓存，每一个环节都有值得抠的细节。这篇文章我就以这个滁州特产商城为样本，把整个项目的架构思路、核心实现、环境部署和排坑经验都盘一遍。无论你是刚学完SpringBoot想找个完整项目练手，还是正在准备课程设计答辩，这都算是一份能直接抄作业的实战参考。

1. 项目概述与技术背景

1.1 项目定位：特产电商的"小而全"特征

滁州特产这个选题并不是随手拍的。滁菊、琅琊酥糖、管坝牛肉、女山湖大闸蟹、来安花红这些区域特色商品，线下销售渠道非常依赖游客和本地市场，疫情之后大家都在想怎么把线上商城做起来。这种"区域特色+电商"的组合，业务模型比普通杂货店更清晰，商品SKU不多，分类明确，客单价集中在几十到几百元——正好是中小型电商系统的典型画像。

从技术角度看，这个系统麻雀虽小五脏俱全。前端用户要能注册登录、浏览分类、搜索商品、加入购物车、下订单、在线支付（或模拟支付）；后台管理员要能维护商品分类、上下架商品、处理订单状态、管理用户、发公告。这一套流程跑通，几乎覆盖了Java Web开发里所有核心场景，这也是为什么导师和面试官都愿意看到这类项目——它不是一个"玩具"，而是一个能讲出完整业务闭环的系统。

1.2 技术选型：为什么是SpringBoot + Vue这套组合

技术栈选型没有高低之分，只有合不合适。这个系统最终采用的主流方案是：SpringBoot 2.x作为后端基础框架，MyBatis-Plus做ORM，MySQL存业务数据，Redis做热点缓存，前端用Vue 3 + Element Plus构建管理台，用户端则用H5响应式页面。有人可能会问，为什么不用微服务？答案很简单：这个项目体量下，微服务只会引入无谓的复杂度。服务拆分的收益来自独立部署、独立扩展、独立团队协作，而这些对于一个单体商城系统来说都是伪需求。

单体应用加上合理分层，反而更适合学习和维护。Controller层负责接收参数和结果包装，Service层处理业务逻辑，Mapper层对接数据库，这三层职责清晰，排查问题的时候从接口一路点到SQL，逻辑链条非常短。SpringBoot在这套体系里的价值在于自动装配和约定优于配置。比如你用spring-boot-starter-web引入Web能力时，SpringBoot通过spring.factories自动装载DispatcherServletAutoConfiguration等配置类，把内嵌Tomcat、SpringMVC、Jackson这些组件一次性装配好，开发者不需要去写一堆XML配置文件。理解了自动装配的原理，你对这个框架的掌控力会提升一大截——面试问到"SpringBoot自动装配原理"时，能答出@SpringBootApplication→@EnableAutoConfiguration→AutoConfigurationImportSelector→ 扫描META-INF/spring.factories→ 按条件装配这个链路，基本就是满分回答。

1.3 项目的学习价值与适用人群

这个项目适合谁？我大概分为三类：第一类是刚学完Java基础和SpringBoot，想找个完整项目串一遍知识点的初学者，能从这里学会怎么搭项目、怎么写Mapper、怎么处理跨域、怎么做登录拦截；第二类是正在做课程设计或毕业设计的在校生，可以直接参考它的模块划分和数据库设计，在此基础上扩展自己的创意；第三类是准备Java面试的求职者，很多面试题——比如JWT鉴权、Redis缓存穿透与雪崩、事务失效场景、XSS攻击过滤——都能在这个项目里找到具体的代码落脚点，比死记八股文强得多。

2. 数据库设计与核心业务模型

2.1 核心表结构与业务关系拆解

商城系统的数据库设计，核心原则是"用空间换清晰，不搞过度设计"。这个项目的表结构大致如下：

这里插一句设计经验：订单商品快照（order_item里的product_name、product_image、price）是非常重要的。很多人第一次设计商品表时，订单明细直接外键关联商品表，下单后查明细实时JOIN主表。这看起来很省事，但一旦后台改价、改名或者下架商品，历史订单就会被篡改。电商系统里订单是交易凭证，必须做到用户下单那一刻的状态完全冻结，所以快照字段是标配。

商品表和分类表之间用category_id关联，我建议分类设计成可扩展的父子级结构，用parent_id字段实现树形。滁州特产虽然规模不大，但将来可能扩展出"茶饮类""肉禽类""干货类"的一级分类，每个一级分类下又有二级分类，提前兜住这种扩展需求，避免后面改表结构。

2.2 订单状态机的设计思想

订单状态是整个电商系统最核心的状态集合。这个项目里的订单状态我梳理成一条单向流转链：

待付款 → 待发货 → 待收货 → 已完成

在这条主链之外，还有"已取消"和"售后中"两个分支。代码实现上，不建议用状态值散落各处直接set。更稳妥的做法是做一层OrderStatusEnum枚举统一管理，每个枚举携带状态码、状态描述以及允许流转到哪些状态的规则。举例来说：

public enum OrderStatusEnum { WAIT_PAY(0, "待付款", new Integer[]{1, 4}), WAIT_SHIP(1, "待发货", new Integer[]{2, 4}), WAIT_RECEIVE(2, "待收货", new Integer[]{3, 4}), FINISHED(3, "已完成", new Integer[]{}), CANCELED(4, "已取消", new Integer[]{}); private final Integer code; private final String desc; private final Integer[] nextStatus; // 构造函数和getter省略 }

这样设计的好处有两个：第一，业务层调用状态流转时，可以先校验当前状态是否允许跳到目标状态，避免出现"已发货的订单被取消发货"这类逻辑混乱；第二，代码的可读性大幅度提升，新接手的人看一眼枚举就知道整条状态链长什么样。很多系统烂就烂在状态散落各处，出现"幽灵订单"的时候根本查不出原因。

支付环节在课设项目里通常是模拟支付，前端调/api/order/pay接口，后端把订单状态从待付款改成待发货，同时扣减商品库存。这里有一个容易忽略的并发问题：用户支付时商品的最终库存可能已经低于下单时的数量。标准做法是在支付成功回调里再次校验库存，如果不足就直接标记订单异常并联系用户退款，而不是把库存扣成负数。项目里我用的是乐观锁方案，在product表加version字段，SQL末尾追加AND version = #{version}，更新时version+1，更新行数为0说明库存被并发改了，触发重试逻辑。

2.3 索引与查询性能的细节

很多人做课设时会忽略索引，因为数据量小感觉不到差别。但面试官和导师会问"你怎么保证商城查询性能"。本项目中我加了这么几个关键索引：orders.user_id索引支持用户订单列表查询，orders.order_no唯一索引保证订单号不重复，product.category_id索引支撑分类商品列表，product.status索引配合后台管理筛选上下架商品。注意不要每条记录都加索引，索引本质上是拿写性能换读性能，像product.detail_images这种长文本字段加了索引也没有意义。

3. 核心功能实现与实战代码解析

3.1 基于JWT的用户登录鉴权链路

用户模块没什么花头，但要做得规整。密码存储绝对不能用明文，也不能只用MD5——MD5在彩虹表面前等于裸奔。我在这套系统里用的是BCrypt强哈希，Spring Security自带BCryptPasswordEncoder，new BCryptPasswordEncoder().encode(password)生成的结果自带随机盐，每次哈希结果都不一样，但matches()校验方法能正确比对。这一点在就业之后几乎是团队标配，提前养成习惯没坏处。

登录成功之后签发JWT，流程是：用户提交username和password → 后端校验BCrypt → 生成token返回前端 → 前端把token存到localStorage或pinia状态里 → 之后每个请求的Authorization头带Bearer token→ 后端通过拦截器解析token并放行。

核心拦截器代码写出来并不复杂：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = Jwts.parser() .setSigningKey("your-secret-key".getBytes(StandardCharsets.UTF_8)) .parseClaimsJws(token) .getBody(); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"登录已过期，请重新登录\"}"); return false; } } }

光有拦截器还不够，还得在WebMvc配置里把它注册进去，并排除登录、注册、商品列表等不需要鉴权的路径。这里有一个我在课设里常看到的问题：有人把拦截器注册之后发现登录接口也被拦了，一看原因是排除路径写错了实际请求路径。建议注册的时候直接打印一遍所有排除的路径和实际访问的路径，比对确认。

3.2 商品模块与Redis缓存策略

商品模块的业务逻辑比较直观：按分类查列表、根据关键词搜索、点进详情。但这里有一个性能优化的经典考点：首页和热门分类的访问频率极高，每次都去MySQL查库，数据量一大数据库就吃力。项目的方案是引入Redis做缓存，商品详情、首页分类商品列表的缓存策略是：先查缓存，缓存未命中则查库，再回填缓存，设置过期时间，也就是业界常见的Cache Aside模式。

用SpringBoot做这件事非常顺手，先引入依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

然后在Service里写缓存逻辑：

public ProductVO getProductDetail(Long productId) { String key = "product:detail:" + productId; ProductVO productVO = (ProductVO) redisUtil.get(key); if (productVO == null) { productVO = productMapper.selectDetailById(productId); if (productVO != null) { redisUtil.set(key, productVO, 30, TimeUnit.MINUTES); } } return productVO; }

这个逻辑本身不难，难的是背后那几个面试必问的问题。缓存穿透怎么解决？解决方案是缓存空值，查询结果为空时也在Redis里写一个空占位，但过期时间设短一点，比如3分钟；缓存雪崩怎么解决？给不同key的过期时间加一个随机数，避免同一时刻大面积失效；缓存击穿怎么解决？对热点key加互斥锁，只让一个请求去查库重建缓存，其余请求等待或者直接返回旧值。有精力的话可以升级到Caffeine本地缓存+Redis两级缓存，访问速度会更快，但这属于加分项，课设里做到Redis这一层已经完全够用。

3.3 购物车与订单模块的实现细节

购物车是本项目里接口最多、最容易写乱的部分。加购物车、改数量、勾选/取消勾选、删除、批量结算，每个接口都要先确认归属：这个购物车条目是不是当前登录用户的。很多初学者图省事，直接按购物车id删除，结果用户A删掉了用户B的购物车记录，这是严重的越权漏洞。正确的做法是每条购物车记录的删除、修改SQL都加上AND user_id = #{userId}条件。

我这里建议把购物车条目存Redis Hash而不是数据库表。原因很简单，购物车是高频读写但数据量极小的场景，每次加减都写MySQL很浪费。Redis数据结构上用Hash，key是cart:userId，field是商品id，value是数量，用户在商城页面实时查到的购物车角标数量就是从Redis读的。不过如果你做的是毕业设计，答辩时有可能会被问到"数据安全性"——Redis默认不做持久化，宕机可能丢数据，所以订单和商品这些核心数据必须落MySQL，购物车这种可以重建的数据放Redis完全没问题。

订单流程的核心接口是提交订单。这里要串联的步骤比较多：接收前端传来的地址id和商品id列表 → 锁定商品库存（扣减Redis中的库存临时值） → 计算总价 → 生成订单号和订单明细快照 → 创建订单主记录 → 从购物车移除已购买商品 → 返回订单号给前端跳转支付。事务必须加在Service层方法上，用@Transactional(rollbackFor = Exception.class)，注意不要只写@Transactional，因为默认只在遇到RuntimeException时才回滚，而很多自定义业务异常是继承Exception的，不加rollbackFor会导致库存扣了但订单没生成却没回滚的情况。

3.4 全局过滤器处理XSS安全问题的实践

商城系统是公网Web应用，XSS攻击是必须要防的。比较常见的场景是用户提交的商品评论、收货地址、后台公告里被插入了<script>标签，存储型XSS一旦执行，能偷走用户cookie和登录态。

我的做法是自定义一个XssFilter，在请求进入Controller之前，把请求体中所有参数的尖括号等敏感字符转义。实现上核心是重写HttpServletRequestWrapper的getParameter、getParameterValues和getInputStream方法：

public class XssStringJsonSerializer extends JsonSerializer<String> { @Override public String serialize(String value, JsonGenerator gen, SerializerProvider serializers) throws IOException { if (value == null) { gen.writeNull(); return; } String cleanValue = HtmlUtils.htmlEscape(value, "UTF-8"); gen.writeString(cleanValue); } }

我用的是Jackson全局配置方案：在ObjectMapper里注册XssStringJsonSerializer，让所有String类型的字段在反序列化时自动做HTML转义，同时配合一个ServletFilter处理URL参数。这种方式比在业务代码里一个一个手动调用escapeHtml()要省心得多，也不容易漏掉字段。需要注意别把整个请求都转义导致用户提交的正常中文符号&变成乱码，所以HtmlUtils的escape策略要选用转义<、>、"、'等危险字符，而不是全量转义。

4. 环境搭建与部署运行实操

4.1 本地环境准备与项目导入

这个项目默认的开发环境是JDK 1.8（也可以用JDK 11）、Maven 3.6+、MySQL 5.7或8.0、Redis 5.x以上、IDEA 2020之后版本。新手最容易踩的坑是JDK版本和SpringBoot版本的匹配问题。如果用了SpringBoot 2.3.x，配Java 8完全没问题；如果你用的是SpringBoot 3.x，那JDK必须17以上，两者的包名、javax和jakarta命名空间都不一样，代码里还是javax.servlet的写法，放到SpringBoot 3.x下直接编译不过。

导入项目时我建议分三步做：第一步，IDEA里File -> Open选择项目的根目录，等Maven把依赖拉完，这里推荐配置阿里云Maven镜像，不然依赖下载能卡半小时；第二步，本地创建MySQL数据库，执行项目sql目录下的初始化脚本，注意脚本里如果有DROP TABLE IF EXISTS，在已有数据的库上执行前先备份；第三步，修改application.yml里的数据库账号密码、Redis地址和端口，启动AdminApplication或ShopApplication主启动类。

4.2 配置文件的核心参数调整

application.yml是SpringBoot项目的枢纽配置文件，我把这套系统里最关键的几个配置点列出来：

server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/chuzhou_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

有两个配置最容易被忽略：第一个是serverTimezone=Asia/Shanghai，不加上这个，MySQL 8.0的驱动会报时区错误，或者查出来的时间和北京时间差8个小时；第二个是allowPublicKeyRetrieval=true，MySQL 8.0默认的caching_sha2_password认证方式会让连接时报"Public Key Retrieval is not allowed"。

4.3 Docker容器化部署SpringBoot项目

本地能跑通只算完成了一半，现在部署交付几乎都会问Docker。我们先写一个Dockerfile：

FROM openjdk:8-jdk-alpine MAINTAINER chuzhou-shop RUN apk add --no-cache tzdata ENV TZ=Asia/Shanghai WORKDIR /app COPY target/chuzhou-shop.jar /app/app.jar EXPOSE 8080 ENTRYPOINT ["java", "-Dfile.encoding=utf-8", "-jar", "/app/app.jar"]

构建镜像只需要一句docker build -t chuzhou-shop .，启动也是docker run -d -p 8080:8080 --name shop chuzhou-shop。生产环境一般还要把MySQL和Redis也用容器编排起来，用docker-compose一步步启动：

version: '3.8' services: mysql: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: 123456 MYSQL_DATABASE: chuzhou_shop ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:6.2 ports: - "6379:6379" app: build: . ports: - "8080:8080" depends_on: - mysql - redis

注意depends_on只是控制启动顺序，它不会等MySQL完全就绪才启动app，所以Java应用第一次连不上数据库导致启动失败时，正确的操作是docker restart shop重启应用容器，而不是反复改代码。更优雅的方案是用Spring Boot Actuator的/actuator/health实现健康检查，让编排器自己判断依赖是否就绪。我给这个项目加过一次，实测下来部署稳定很多，推荐有精力的人折腾一下。

4.4 演示运行视频里那些需要注意的细节

项目资料里附带的运行视频和讲解视频，核心目的是帮助使用者确认"这套系统能跑起来、能演示完整流程"。结合我过往指导经验，录运行视频时建议按这条主线来：启动Redis → 启动MySQL → 启动后端 → 启动前端 → 注册一个用户 → 浏览商品 → 加入购物车 → 提交订单 → 模拟支付 → 后台管理端登录 → 发货 → 用户确认收货。这条链路把商城的两大核心角色和完整状态流转都覆盖了，答辩论证和自行验证都够用。

有个操作细节要提醒：视频里录到模拟支付时，项目的前后端时间可能会显示不一致，因为数据库的timestamp字段在JDBC连接时如果用默认时区就可能读取偏差。录视频之前先确认MySQL的default-time-zone字段是+08:00，避免演示时订单创建时间和支付时间差了8个小时，答辩被评委抓个正着。

5. 常见问题排查与避坑指南

5.1 数据库初始化与访问异常

项目解压之后第一步就翻车的概率很高。最常见的是把chuzhou_shop.sql在Navicat里执行时报"Unknown character set 'utf8mb4'"或者中文乱码。前者一般是你MySQL版本过老，解法是升级到5.7.20以上，或者把脚本里所有utf8mb4手动替换成utf8；乱码问题则多半是连接串里没有characterEncoding=utf8。

还有一类用户习惯用root账号连库，但MySQL 8.0的root默认用caching_sha2_password，老版本驱动连不上。我建议新建一个专用账号，并赋予该业务库全部权限，这样既能跑通，也避免把root密码暴露在代码仓库里，实际开发里这是一个基本的安全习惯。

5.2 图片上传失败与访问404

特产商城必然有大量商品图片，图片上传模块是重灾区。我碰到过两类典型问题：一是上传路径配错，后端把图片写到了D:/upload/，但项目部署在Linux服务器上，路径不存在；二是前端访问图片地址404，因为后端没做静态资源映射。

正确的做法是把图片上传的根路径单独拎出来配置，并在WebMvcConfigurer里做虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); } }

这样浏览器访问http://localhost:8080/upload/product/xxx.jpg就能直接命中文件。核心经验是：页面上的图片URL只存相对路径/upload/product/xxx.jpg，不要存http://localhost:8080/upload/...这种绝对路径，否则一旦换域名、换端口，所有图片全部失效。

5.3 订单支付成功但状态没更新

这是电商项目里最让人抓狂的Bug之一。排查思路我总结为三步：先看请求是否真的到达了后端？打开浏览器Network，找到支付接口，看返回码；再看后端日志里有没有完整执行到更新订单状态的SQL；最后看事务是不是把异常吞了。

我遇到过一个隐藏比较深的坑：支付接口方法里，扣库存成功了，但更新订单状态时因为状态码不匹配抛了异常，整个事务回滚。但前端因为接口没及时返回就以为支付失败，然后用户再点一次"支付"，系统判断订单已支付又提示"重复支付"，两端状态就打架了。解决办法有两个：一个是支付与回调接口设计成幂等，同一个订单号重复支付时直接返回成功状态；另一个是支付成功回调采用异步通知+状态校验，核心逻辑就是先查订单当前状态，如果已经是待发货就直接返回，不进行二次扣减。

5.4 前台页面跨域请求失败拦截

前后端分离部署后，最常见的报错是Access-Control-Allow-Origin。后端需要支持跨域请求，我建议一次性全局配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意allowedOrigins("*")和allowCredentials(true)不能同时使用，后者要求指定具体的OriginPatterns，很多初学者在这里反复踩坑。

5.5 Maven依赖冲突与Lombok版本兼容性

Maven依赖冲突的经典表现是启动时NoSuchMethodError或者ClassNotFoundException。排查工具很简单：在IDEA的Maven面板点Show Dependencies，检查有冲突的依赖。商城项目里经常出问题的是jackson-databind和fastjson混用，两者在很多注解和类型转换上的行为不同，建议只保留一个JSON库。我用的是Jackson全家桶，SpringBoot默认就是它。

Lombok与JDK版本不匹配也会导致编译失败。JDK 8用户用最新版Lombok没问题，但如果你换了高版本JDK（比如JDK 17），而Lombok版本还是1.16.18，就会报Could not initialize class lombok.ast.AST。解决办法是把Lombok升到1.18.20以上。另外，IDEA里一定要安装Lombok插件并开启Enable annotation processing，否则@Data不会生成getter/setter，启动直接报一堆"找不到符号方法"。

5.6 SpringBoot高版本版本差异注意点

热词里有人提到"springboot版本太高"，确实是这样。SpringBoot 2.7和3.x之间的差异，不只是JDK要求变了，很多配置类的位置、spring.factories机制（3.x改成了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports）、RedisConfig写法都有变化。如果你拿到的是基于SpringBoot 2.3的项目模板，不要轻易升级到3.x；反之如果你是从零搭建新项目，建议直接上SpringBoot 2.7.18或3.1.x，少走老版本的弯。

另外提一下热词里"springboot banner生成器"——这个小工具有意思，可以在项目启动控制台打一个自定义的ASCII艺术字Banner。实操很简单，用在线Banner生成器生成文本，放到src/main/resources/banner.txt里，启动SpringBoot时会自动打印。项目演示或者录制讲解视频时，这个Banner会让你的答辩画面很有仪式感，是零成本提升观感的好技巧。

6. 项目扩展思路与个人心得

这套商城系统做完之后，如果想让它更有竞争力，扩展方向其实很多。第一个是接入真实支付，使用支付宝开放平台的沙箱环境，测试体验和真实支付几乎一样，只需要在支付宝开放平台申请一个沙箱应用，拿到APP_ID、RSA2密钥，然后替换支付模块的Mock逻辑。第二个是增加搜索功能，目前商品搜索是MySQL的LIKE '%keyword%'，数据量大了之后性能很差，可以把hanlp分词集成到项目里做分词索引，或者直接用Elasticsearch做商品搜索，这个点要是写进简历的"亮点"里，含金量立刻不一样。第三个是后台增加数据可视化，用ECharts展示销售趋势折线图、分类销售占比饼图、热门商品Top10柱状图，这些对于答辩展示非常有说服力。第四是引入SpringBoot整合ActiveMQ或RocketMQ做订单超时自动取消，下单后30分钟未支付自动关单释放库存，这个功能在真实电商系统里是必备的，实现思路就是延迟消息，面试被问到的概率也极高。

最后聊聊我做这个项目最实在的体会：用一个商城系统把SpringBoot整条链路串联起来之后，再看面试题和八股文的感觉会完全不同。很多人问我"java怎么保证数据一致性"，你光背事务隔离级别和分布式事务协议是没有体感的，但你在订单支付的代码里实打实踩过一次"事务没回滚导致库存扣错"的坑，再看到这个问题，脑子里浮现的是具体的代码场景和规避方案，回答自然就立体了。

如果你现在刚拿到类似的商城系统源码，我的建议是：脱离运行视频，自己照着数据库表结构和接口文档，尝试用Postman把核心接口通一遍，然后用Xmind画一张系统的功能结构图，最后再试着自己独立把订单模块写一遍。这个过程下来，你收获的绝不仅仅是一份能跑的项目，而是"能跑"背后的设计思维和排错手感。

趁热打铁，把登录鉴权和订单支付这两个模块的代码多读两遍，面试和答辩的时候，你会发现自己是全班讲得最清楚的那一个。