这两个月我前后协助调试了不下五个毕业设计项目，其中这个"基于SpringBoot的二次元商品商城系统"算是同类里最典型、也最能锻炼人的一个。表面上它就是一个"简化版淘宝"，可真动手做起来，涉及的东西从权限认证到库存扣减、从前后端联调到远程发布，一环扣一环，哪块没处理好，演示的时候都会翻车。今天这篇文章不写泛泛的项目简介，而是把我实际搭建和调试这个项目的过程完整捋一遍，把我踩过的坑、改过的代码、答辩时容易被问的问题都整理出来，给正在做或者准备做同题目的同学一个可以直接参考的路线图。

先给没接触过这类项目的读者交代一下这个系统是干什么的：它本质上是一个面向二次元爱好者群体的B2C电商网站，卖的是手办、模型、谷子、徽章、立牌、海报这些周边商品。系统分前台和后台两部分，前台面向普通用户，支持注册登录、浏览商品、按分类或关键词检索、加购物车、下单结算、查看订单；后台面向管理员，用于管理商品信息、分类、库存、订单状态以及用户状态。整个项目采用前后端分离架构，后端就是标题里的SpringBoot，前端用Vue。

这篇文章适合三类人看：一是正在做这个题目的计算机专业本科生，二是想拿商城类项目练手的初级Java开发者，三是准备答辩但心里没底、想知道老师会怎么提问的同学。我会把从建表到部署、从代码逻辑到调试技巧的完整过程都讲清楚，文里涉及的具体方案都是我实际验证过、能跑通的，你直接照着做基本不会出大问题。

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

1.1 二次元商城项目的需求拆解

很多刚开始做毕设的同学容易犯一个错误，就是把"商城系统"理解成了"商品增删改查"，结果数据库建完、接口写完，满打满算两周就收工了，答辩时老师随便一问"你这个商城和普通商品展示页有什么区别"，直接就卡住了。二次元商品商城和普通电商最大的不同不在技术，而在业务细节。

先说前台用户能感知的部分：二次元商品普遍存在"多规格"概念，一个手办可能分普通版、特典版、豪华版，尺寸还分1/7和1/8，价格和库存都不同；一些热门IP的周边商品会做"预售"，也就是先付定金、到货后再补尾款；还有限量商品的抢购场景。这些我都建议至少在数据库设计里留出对应字段或者状态位，哪怕毕设阶段不把支付和真实物流接进来，表结构上也要能体现这种业务逻辑，这会让答辩的深度完全不一样。

再说后台管理部分：管理员需要能上架商品、维护分类、调整库存、处理订单状态（发货、取消）、管理用户账号。如果时间充裕，再加一个简单的销售统计面板，按天展示订单数和销售额。这里我强调一个很实际的原则：功能宁精勿多，先把闭环走通，再考虑怎么炫。所谓闭环就是用户从注册到下单再到管理员发货，整个流程的数据在数据库里是自洽的、状态是连贯的。

1.2 为什么SpringBoot这套组合最合适

选SpringBoot做毕设，不需要犹豫。现在企业里Java后端开发的主流就是SpringBoot，它把Spring那套繁琐的XML配置几乎全部干掉，改成自动装配和约定优先，一个main方法就能启动内嵌Tomcat跑起来。你自己查资料、问学长、找Bug的时候，网上95%的答案都是围绕SpringBoot的，这就大大降低了排查问题的门槛。

具体版本搭配我建议：SpringBoot 2.7.x + JDK 8 + MySQL 5.7，这套组合最稳。不是说SpringBoot 3.x不好，而是3.0开始强制要求JDK 17，很多老教程里的代码和依赖写法会出现兼容性问题，你抄起来容易翻车。对应的，ORM层用MyBatis Plus，它的BaseMapper直接替你完成了单表CRUD，写复杂查询时再用Wrapper条件构造器，能省掉一大半的SQL编写量。权限控制不用Spring Security，太重了，我下面会讲怎么用一个轻量级拦截器方案解决。

前端选Vue 2 + Element UI，原因就一条：成熟、资料多、UI组件现成。Vue 3当然也行，但如果你的前端功底比较薄弱，Vue 2阶段的相关模板和教程量是最大的，遇到问题搜一搜就有答案。前后端分离的模式一定要坚持，因为答辩老师大概率会问"前后端是怎么交互的"，你能讲清楚Axios请求、接口约定、跨域处理，是一个明显加分项。

1.3 单体架构就够用，别自己给自己加戏

有一种情况很常见：有些同学看了几天微服务的课程，就非要在毕设里拆出Nacos、Gateway、OpenFeign，把商城拆成用户服务、订单服务、商品服务三个微服务。结果开发到一半，光服务间调用、配置中心、分布式事务就把他耗干了，最后demo都跑不起来。

我的观点很明确：毕设阶段就老老实实用单体架构，把精力放在业务逻辑的正确性和代码结构的清晰度上。你在答辩时最有力的论据是"系统稳定、流程完整、逻辑清晰"，微服务就算拆了，老师追问分布式事务怎么处理、服务熔断怎么做，你答不上来反而扣分。单体架构配合前后端分离，已经能体现分层设计能力、接口设计能力和数据库设计能力，对本科毕设来说完全足够了。如果确实想让项目更有"看点"，就做单体+局部扩展点，我在第六部分会讲怎么在不增加太多复杂度的前提下，把缓存、支付沙箱这些加分项加进去。

2. 数据库设计：这个项目的地基工程

2.1 核心表的划分与字段设计

数据库是一个商城项目的命脉，我在调试过的项目里见过太多因为表设计不合理导致的翻车案例：订单表里不存商品快照，导致商品删了之后订单详情显示空白；库存只在商品表里放一个数字，多规格商品完全没法处理。所以这一节我直接把一套经过验证的表结构方案放出来，你直接用或者稍作调整都行。

用户表重点关注角色字段和状态字段：role区分管理员和普通用户，status用来封号，这一步是后台管理的基础。商品表的字段设计我按电商惯例来处理，商品主信息放一张表，多规格信息单独处理。订单表和订单明细表是标准的一主多从结构，订单表存收件人、总金额、状态这些汇总信息，明细表存当时下单的商品快照（名称、图片、单价、数量），做快照的原因很简单：订单是交易凭证，商品后台上架信息改了不能影响已经产生的订单。

我见过有同学把订单明细里的价格直接外键关联商品表去查，这就是典型的"没想清楚业务含义"，商品价格一变，历史订单的金额就跟着变，这在真实业务里是绝对不允许的。字段设计完整表格如下：

2.2 关于多规格存储：JSON方案和独立表方案怎么选

二次元商品的规格是我特别要展开讲的一点，因为普通图书类商品不需要规格，但手办和周边几乎都有版本区别。规格的实现有快慢两条路：

第一条路是"懒人方案"，在商品表加一个specs字段，类型用JSON，把"普通版298元库存500、特典版398元库存120"这样的数据直接塞进去。优点是建表简单，改动量小；缺点是查询和更新麻烦，比如要给特典版减库存，你得先读出整个JSON再修改写回，容易出错，也没法用SQL直接做条件查询。

第二条路是"正经方案"，也就是我表格里列出的独立规格表tb_spec。每个商品对应多条规格记录，每条记录有自己的价格、库存和规格名称。下单的时候前端传spec_id，后端根据spec_id精确锁定价格和扣减库存。这个方案能讲的东西多很多，答辩时你可以顺势解释为什么不用JSON——"JSON字段查询效率低、事务控制不方便"，这句话一出来，老师就知道你思考过这个问题。

2.3 库存扣减与订单状态机设计

库存问题是商城系统里最容易被老师追问的点。直接从商品表扣减库存的SQL要这么写，才能避免高并发下的超卖问题：

UPDATE tb_product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count}

把"剩余库存是否够"的判断放到UPDATE语句的WHERE条件里，让数据库的锁来保证原子性，而不是先SELECT出来再在代码里判断。这是最基础也是最重要的防超卖写法。对于规格表，你只需要把表换成tb_spec，按spec_id扣减即可，原理完全一样。毕设阶段不需要引入Redis分布式锁，但你要能说出"数据库行锁解决并发扣减"这个思路，就已经说明你理解了问题的本质。

订单状态我强烈推荐用整数状态码，比如：0待支付、1已付款、2已发货、3已签收、4已取消。状态流转只在后端Service层里控制，不允许前端直接传状态值。比如"确认发货"这个操作，后端只接受"把1变成2"的合法跳转，如果你传一个3过来就报参数错误。这不仅是良好的工程习惯，答辩时还能顺势引出"状态机设计"这个概念，属于低成本高收益的亮点。

3. 后端核心功能实现：从登录到下单的完整链路

3.1 轻量级JWT登录认证，比Spring Security更适合毕设

说到登录认证，很多教程一上来就让你整合Spring Security，我是不建议的，因为它的过滤器链和多配置源对初学者太不友好，你配了半天被403搞到心态爆炸，还不清楚原理是什么。这里推荐一个折中方案：JWT + SpringMVC拦截器，自己手写，代码量不大，但原理透明。

JWT的思路三句话讲清楚：用户登录成功后，后端生成一个包含用户ID和角色信息的签名Token返回给前端；前端每次请求都在请求头带这个Token；后端用一个拦截器拦截需要认证的接口，解析Token，通过就放行、失败就返回401。具体步骤我在代码里展示：

// JwtUtil.java - 核心方法 public static String generateToken(Integer userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody(); }

拦截器的逻辑更直白：直接判断请求头里有没有合法的Token。管理员接口额外判断role是否等于"ADMIN"。这里有一个实操细节很多人会忽略：JWT解析抛异常的类型要分别处理，Token过期和Token伪造返回的响应消息最好不一样，方便前端做跳转登录和被踢出登录的区分。我实测时发现，有的同学统一返回"未登录"，结果用户只是Token过期，也被强制清空本地存储重新登录，体验很差。

3.2 商品模块接口设计：首页、搜索、分类三大场景

商品接口是整个系统里最繁琐的部分，因为场景多、条件组合也多。我实际开发里把它拆成了以下几类：首页推荐商品（分"新品"和"热销"两个维度），分类浏览，关键词搜索，商品详情。注意，功能可以简单，但接口的"形"要规范。

分页查询是必考内容，MyBatis Plus提供了Page对象，用法我贴一下：

Page<ProductVO> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1) // 只查已上架商品 .eq(categoryId != null, Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getName, keyword) .orderByDesc(Product::getCreateTime); productMapper.selectPage(page, wrapper);

这里有一个非常关键的细节：查询商品列表时，返回给前端的数据应该是一个封装后的VO（视图对象），而不是直接返回数据库的实体。为啥？因为商品表里有detail_images这种长文本字段，列表页根本用不到，直接返回会导致接口载荷变大、响应变慢。正确的做法是定义一个ProductVO只包含列表需要的字段，用BeanUtils.copyProperties做一个属性拷贝。这个点我在答辩培训时反复强调，一个"实体不直接暴露给前端"的回答，比任何花哨的技术名词都更能体现工程素养。

商品详情的浏览量是另一个择加分项：在详情接口里加一个Redis自增或者数据库字段累加，就能在商品列表里按浏览量排"人气"热度。毕设阶段用数据库字段自增就够，int类型的pv字段加1，改动很小，效果很好。

3.3 购物车与下单流程的事务控制

购物车这模块逻辑不复杂，风险点在于"重复加购"。最稳妥的实现是给tb_cart表加一个联合唯一索引(user_id, product_id)，然后使用INSERT ... ON DUPLICATE KEY UPDATE来合并数量。在实际开发里我喜欢先查存在与否再做新增或修改，代码上更直观，也方便你打印日志排查问题。

下单流程是整个系统里复杂性最高的部分，涉及订单主表写入、订单明细写入、库存扣减、购物车清空四个操作，这四个操作必须在一个事务里完成，方法上要加@Transactional注解。事务的意义在于：如果第3步库存扣减成功但第4步清空购物车失败，整个事务会回滚，库存也会恢复，不会出现钱货不一致的脏数据。

下单的代码骨架我贴出来，注释写得详细一点，方便你讲给老师听：

@Transactional(rollbackFor = Exception.class) public OrderVO submitOrder(OrderSubmitDTO dto) { // 1. 生成订单号并创建主表记录 // 2. 遍历dto中的商品列表，从商品表查最新价格（不信任前端传的价格） // 3. 执行优化级UPDATE扣减库存，如果受影响行数为0说明库存不足，抛出业务异常 // 4. 写入订单明细表（保存商品快照） // 5. 批量删除购物车记录 // 6. 返回订单号给前端，引导去支付页面 return null; }

关于金额计算，我有一个强烈建议：所有金额计算以后端为准。前端传过来的totalAmount一概忽略，后端遍历购物车重新从数据库查单价再累加。这么做不是不信任用户，而是防止有人通过篡改前端请求来低价下单，这是一个安全边界问题。答办时你要能主动说出"前端金额不可信，后端必须二次计算"这句话，几乎就是一个加分回答。

3.4 后台管理的权限控制与文件上传

管理端的分权比较简单：用户表的role字段已经区分了管理员和普通用户，拦截器里对admin/**路径额外校验role即可。有个同学问过我一个问题："拦截器校验不通过就返回401，前端跳转登录页面就好了，但是管理员管理商品的时候，图片上传是不是也要权限？"答案是当然要，你的上传接口只要挂在管理员的Controller里，它就会自然被拦截器保护，这就是"路径即权限"的设计思路，非常清晰。

商品图片上传这块，毕设不需要接OSS，直接把图片存到本地服务器的指定目录，然后通过一个映射把访问路径暴露出去。SpringBoot里配置静态资源映射的写法：

spring: web: resources: static-locations: file:D:/upload/,classpath:/static/

注意Windows和Linux的绝对路径格式不一样，别写死。我这边就处理过把路径写成D:/upload/、结果部署到Linux服务器上全404的情况。跨平台的做法是配置文件里用占位符，或者直接用相对路径加System.getProperty("user.dir")拼接。

我额外提醒一个上传文件的坑：SpringBoot默认上传单个文件最大1MB，新手传个大图就报500，但你看到后台日志里不是"文件太大"而是奇奇怪怪的转换异常，排查半天。这个问题在application.yml里把大小调大就好：

spring: servlet: multipart: max-file-size: 20MB max-request-size: 50MB

4. 前端页面与前后端联调：五个最常见的开发坑

4.1 前端页面的路由设计与权限控制

前端这一块我不会展开讲每一个页面怎么写，而是把"骨架思路"给你理顺。项目的页面分为六大块：商城首页、商品列表页、商品详情页、购物车页、订单确认与支付页、个人中心，外加一个后台管理面板。Vue Router的配置里要特别注意：需要登录才能访问的路由，统一配置meta: { requiresAuth: true }，然后在全局前置守卫里做判断。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.matched.some(r => r.meta.requiresAuth) && !token) { next('/login?redirect=' + to.fullPath) } else { next() } })

这个方案比在每个页面里做if判断要优雅太多，也是面试常考的前端路由守卫知识点。同理，管理端页面配置meta: { role: 'ADMIN' }，守卫里多一层角色校验，就可以了。

二次元商城的首页视觉比较重要，建议首页直接放一个轮播图（Banner）、一排"热门新品"，再按照IP分类展示商品卡片。这些数据不硬编码在页面里，而是调后端的接口拿到。如果后端还没写完，就用Mock数据先撑页面，等接口好了再接上，前后端并行开发靠的就是这层Mock的灵活约定。

4.2 前后端联调：跨域、Axios封装与字段命名

联调是毕业设计阶段最容易让人崩溃的环节，几乎所有的"白屏"和"接口报错"都集中在下面几个根源上：

第一，跨域问题。如果你用Vue CLI的devServer运行前端开发环境，端口是8080，后端是8081，两边端口不同，浏览器的同源策略就会拦截。开发阶段的解法是在vue.config.js里配置代理：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

这样前端写的请求路径如果是/api/product/page，代理就会转发到后端的http://localhost:8081/api/product/page，浏览器看到的是同一端口，就不会报跨域了。生产部署阶段，你用Nginx反向代理同样能解决，这个方案我必须强调：毕设项目别在后端直接全局配置CORS允许所有来源，虽然能用，但答辩时被问到安全性会掉印象分。

第二，Axios统一封装。每个请求都要带Token，你不可能每次手动写请求头，用一个Axios实例加拦截器搞定：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) config.headers['Authorization'] = 'Bearer ' + token return config }) service.interceptors.response.use( resp => resp.data, err => { if (err.response.status === 401) { localStorage.clear() router.push('/login') } return Promise.reject(err) } )

这里用一个细节提醒你：如果你后端返回401的方式是直接设置响应状态码，前端拦截器处理起来就干净利落；但有些同学后端图省事，HTTP状态码一律返回200，只在body里写code=401，这样前端拦截器就废了。我强烈建议你后端返回标准HTTP状态码，因为前端拦截器、Nginx日志、浏览器调试面板都是认状态码的，这是一套统一的"行业标准"。

第三，字段命名规范。我见过一个项目，后端返回的是createTime，前端用的是create_time，结果列表页时间永远为空。前后端字段约定要统一，推荐都用驼峰命名，后端JSON序列化时框架默认就是驼峰，前端直接使用即可，避免来回转。另外时间日期格式建议统一为"yyyy-MM-dd HH:mm:ss"，JSON里带ISO串的话，展示的时候还要再格式化，纯属给自己添堵。

5. 部署发布与远程调试：帮别人跑通项目的实战记录

5.1 远程调试配置：从零到能连上的完整过程

毕设的项目几乎都有"远程调试"这个需求，原因很简单：很多同学的电脑配置一般，或者做演示的时候可能不在自己电脑旁边，需要远程帮着解决问题。我接触的这个项目也是，学弟把项目从一台电脑挪到另一台电脑跑，数据库、环境全都是新的，我搭好环境之后还要确保后续出了问题能远程介入。这一节我就把Java应用的远程调试配置完整讲一遍。

远程调试的原理本质上是JVM开放一个调试端口，允许IDE远程连接上去打断点。SpringBoot项目启动时加上一段JVM参数：

java -jar xxx.jar --server.port=8081 \ -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

意思解释一下：transport固定用dt_socket，server=y表示目标应用作为调试服务器，suspend=n表示启动时不等待调试器连接，端口选5005，asterisk表示允许任意IP连接。注意我量过一次：suspend=y的话，就是你远程IDE没连上，应用就卡着不启动，演示时极其尴尬，一定要用n。

在IDEA里的配置路径是Run/Debug Configurations，新增Remote JVM Debug，Host填服务器IP，Port填5005，然后点击Debug按钮就能连上。连上之后，在代码里打断点，远程请求过来就会在你本地IDE里停下来，你可以单步调试、看变量、找问题。这个功能对排查生产环境Bug非常实用，也是企业里调试线上服务的常见手段之一。

但这里有一条安全红线我必须提醒：远程调试端口在生产环境绝对不能开着，因为它等于把应用的后门公开了，任何能连到这个端口的人都能控制你的JVM。毕设演示或者开发环境用没问题，但演示完最好关掉。你自己心里要清楚，这个工具是调试用的，不是部署标配。

5.2 环境迁移与数据库初始化注意事项

环境迁移最常见的坑集中在数据库环节。我这里记录一下完整的搬运流程：先在新的机器上安装MySQL，创建数据库并设置好编码为utf8mb4，导入SQL脚本，再用SpringBoot配置文件连接。SpringBoot连接MySQL时有一个高频报错就是时区问题，报错信息长这样：The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，实际上就是时区没配置。连接串里加上serverTimezone=Asia/Shanghai，问题就解决了。

spring: datasource: url: jdbc:mysql://localhost:3306/second_hand_mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码

另外一个高发问题是端口占用。8081被占用了项目起不来，用命令查一下就知道是谁在占用：

# Windows netstat -ano | findstr 8081 # Linux / macOS lsof -i:8081

把占用进程kill掉，或者改application.yml里的server.port都行。我把常见排查场景整理成一个速查表，方便你对照解决问题：

5.3 演示前必做的三次完整走查

远程调试搞定不代表演示万事大吉，我吃过亏才总结出这套必做的演示前检查清单。第一遍走查"注册到下单"的完整路径：注册一个新用户，登录，搜索一个商品，加入购物车，提交订单，模拟支付，在后台看到这笔订单。第二遍走查"管理端操作路径"：新增一个分类、上架一个商品、修改库存、对订单执行发货。第三遍走查"异常场景"：故意输错密码、访问不存在的商品ID、未登录就访问购物车页面、支付库存不足的商品。三遍走完，常规情况下演示不会翻车。

我还遇到过一种"打脸场景"：项目在学校教室演示时，教室的WiFi屏蔽了某些端口，或者必须开代理才能上网，而前端页面和Axios请求需要的端口没有放行，导致白屏。这时候有两个稳妥解法：一个是把请求路径改成相对路径，让演示环境走同一端口的代理转发；另一个是提前把演示用的域名或IP写死到前端配置文件里，不依赖DHCP动态分配的地址。这类环境类问题不太会引起重视，但每年演示季都会绊倒一批人。

6. 这套系统还能怎么扩展：实用路线和真实体会

6.1 加分项扩展：Redis缓存、支付宝沙箱、搜索优化

如果你答辩前还有两周以上的富余时间，我建议从以下三个方向里挑一个做扩展，不要贪多。第一个是Redis缓存热点数据：把首页推荐商品和商品详情缓存到Redis，设置过期时间比如10分钟，能明显降低数据库压力。加入这一块之后，代码结构从Controller直接调Service变成了Controller先查缓存、缓存没有再查数据库、然后把结果写入缓存，逻辑清晰，也容易讲解。Redis在毕设项目里出现频率非常高，不算过度设计。

第二个是接入支付宝沙箱支付。这里很多人有误解，认为接支付需要企业资质和真实商户号，其实支付宝沙箱环境是专门给开发者测试用的，有固定的测试账号和测试钱包，流程完全模拟真实支付，接入代码也不复杂。你只需要在支付宝开放平台申请沙箱应用，配好RSA2密钥，后端集成Alipay SDK，下单后返回支付链接，支付回调里更新订单状态。这一坨做完，你的项目在演示时可以直接现场扫码支付（虽然是模拟），那个效果比任何PPT都震撼。

第三个是Elasticsearch做商品搜索。这个方向难度略大，需要额外安装ES环境，但如果你的毕设选题本身没什么亮点，能演示"搜索出结果只要200毫秒"这种性能对比，会是很有说服力的加分项。注意ES本质是一个独立的搜索引擎，你需要把MySQL里的商品数据同步过去，同步工具有logstash或定时任务，这又是一堆工作量，所以我把它放在最后一位推荐。

6.2 我从这个项目里最深的几点体会

最后真实说几句做这类项目的心得。数据库设计真的是整个工程的底盘，我调试过的最折磨的项目，几乎都是表结构没设计好：要么缺字段导致业务逻辑没法展开，要么字段命名混乱导致前后端联调时反复返工。你花在画ER图和设计字段上的时间，会在后续开发里以十倍的时间省回来，这个比例毫不夸张。

第二个体会是"让项目始终保持能跑的状态"。很多同学的习惯是把功能全写完再统一测试，结果一到测试阶段全盘崩溃，查起来无从下手。更合理的做法是分模块推进：用户模块写完了就启动跑一遍，商品模块写完了再跑一遍，每次只改动增量部分，一旦出现问题，你很清楚是刚写的代码引入了Bug。我调试项目时坚持的就是这个思路，效果非常明显。

第三个体会是关于心态的：演示翻车大概率不是你运气差，而是你准备不到位。我在调度这个系统的过程里，至少遇到过五次"改了一行代码、结果另一个功能挂掉"的连锁问题，原因就是模块间的耦合和全局状态没有控制好。如果你能在编码阶段就坚持分层清晰、接口自洽，这些问题大概率就不会出现。

这篇内容写了很长，但每一段背后都是我实际调试项目时碰到并解决过的真问题。你照着这个路线把项目做完、讲清楚，不说拿满分，至少能在答辩时做到心里有底。这个商城系统后续如果打算继续演进的话，沿着微服务拆分、消息队列做订单异步处理的方向走也完全有余地，但那是下一个阶段的故事了。