企业官网建设流程全解析

前阵子帮一个做社区零售的朋友搭建后台，聊着聊着发现很多刚接触 SpringBoot 的毕业生，或者说想转后台开发的同学，对"商品管理后台系统"这个题目的理解还停留在"CRUD 四张表"的层面。实际上，一个能真正跑在零售业务里的后台运营平台，远比想象中复杂：库存怎么扣才不出负数、订单状态怎么流转才不混乱、商品上下架和 SKU 怎么关联，这些才是毕业设计答辩时真正能拿得出手的亮点。这篇就基于我实际开发 SpringBoot 零售商品后台运营平台的经验，把商品、库存、订单中心这三条主线的设计与实现完整拆开聊一聊，适合正在做 SpringBoot 毕设、或者想系统理解电商后台核心模块的读者参考。

1. 项目背景与需求分析：零售后台到底要解决什么问题

1.1 零售后台的业务痛点拆解

很多同学拿到"商品管理后台系统"这个题目时，第一反应是"做个页面增删改查就完事了"。但如果你真的去问一个开超市或者做电商运营的人，他们最头疼的往往是这几件事：商品信息散落在 Excel 里，谁改了什么没人知道；库存数量月底对不上账，既不知道什么时候该进货，也不知道哪些商品卖不动该下架；订单全靠人工记，发货状态、退款状态全靠脑子硬记，一忙就乱。所以这个系统的价值，本质上是把这三件事从"人肉管理"变成"系统化运营"。

我在设计时把核心需求拆成了三条主线：商品生命周期管理（从录入、上架到下架）、库存实时变动追踪（入库、出库、预警）、订单状态的闭环流转（下单、支付确认、发货、完成）。这三个模块看似独立，实际上是一条完整的数据链路：商品产生库存，库存被订单消耗，订单反过来又驱动库存变化。

1.2 功能模块划分与优先级排序

做后台系统最容易犯的错误是一上来就想把所有功能都做全，结果连基础的主流程都没跑通。我当时的做法是先用 80% 的精力保证主链路的完整可用，剩下 20% 再去做锦上添花的功能。

这个优先级排序背后有个很实际的理由：毕设答辩或者项目演示时，考官最关心的是"你的系统能不能支撑一个完整的业务流程"。如果订单创建完库存没减，或者商品下架了订单还能继续买，那功能再多也白搭。先把主链路打通，再补权限和统计，整个项目的完成度和说服力会高很多。

2. 技术选型与架构设计：为什么是 SpringBoot 这套组合

2.1 技术栈的选型依据

SpringBoot 能成为 Java 后端开发的事实标准，不是没有原因的。对于这种后台管理类系统，它最舒服的点在于"约定优于配置"：不需要像传统 SSM 那样写一大堆 XML 配置，一个@SpringBootApplication注解跑起来，内嵌 Tomcat，一个 jar 包就能部署。我当时选用这套组合，具体是这么搭配的。

• 核心框架：SpringBoot 2.x + Spring MVC，负责 RESTful API 接口和请求分发
• 持久层：MyBatis-Plus，配合它的BaseMapper可以省掉大量单表 CRUD 的重复代码
• 数据库：MySQL 8.x，存储业务数据，InnoDB 引擎保证事务
• 前端：Vue + Element UI，前后端分离，方便演示时快速调整页面
• 认证方案：JWT 做无状态登录，接口签名校验避免越权访问

为什么不用 MyBatis 原生版？不是说它不好，而是对于商品、库存、订单这种大量单表操作、少量复杂联表查询的场景，MyBatis-Plus 的LambdaQueryWrapper写起来实在太顺手了。比如筛选"状态为上架且库存小于预警值"的商品，一行条件构造器就搞定，不用在 XML 里手写动态 SQL。

2.2 后端工程结构与分层思路

项目的包结构我习惯按"业务域"划分，而不是按"技术层"划分。这样做的最大好处是：当你新增一个商品批量导入功能时，你能很清楚地知道该改哪几个类，而不是把 controller/service/mapper 各层的同名包翻个底朝天。

com.retail.platform ├── controller // 接收请求、参数校验、返回统一响应 │ ├── GoodsController │ ├── StockController │ └── OrderController ├── service // 业务逻辑层，事务边界在这里 │ ├── GoodsService │ ├── StockService │ └── OrderService ├── mapper // 数据访问层，继承 BaseMapper ├── entity // 数据库实体映射 ├── dto // 入参出参对象，避免实体直接暴露 ├── common // 统一返回结构、异常处理、工具类 └── config // 配置类，如拦截器、跨域、Knife4j

这里想特别说一下dto这层。很多初学者喜欢把Goods实体直接当作接口参数和返回值传来传去，图省事。但实际开发中你会发现，前端传来的参数往往比实体字段少（比如只需要商品名、价格、库存），返回给前端的数据又往往比实体字段多（比如要带商品分类名称、库存状态描述）。如果始终用实体传，最后每个接口的参数校验都写得极其别扭，还容易暴露数据库表的敏感字段。这也是我踩过坑之后才体会到的事。

3. 数据库建模：库存与订单的数据闭环设计

3.1 核心数据表结构设计

数据库设计是整个零售后台系统的地基，地基歪了，后面写多少代码都别扭。我按照业务链路拆出了这几张核心表。

首先是goods商品表，这张表承载商品的基础信息：

CREATE TABLE `goods` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `goods_name` VARCHAR(128) NOT NULL COMMENT '商品名称', `category_id` BIGINT NOT NULL COMMENT '分类ID', `goods_sn` VARCHAR(64) NOT NULL COMMENT '商品编码，唯一', `price` DECIMAL(10,2) NOT NULL COMMENT '销售单价', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-下架 1-上架', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_goods_sn` (`goods_sn`) ) COMMENT='商品基础信息表';

然后是stock库存表，这里我选择了把库存单独拆出来，而不是塞进商品表。原因是：商品信息是相对静态的（改个名字、换个价格），库存是高频变动的（每次订单产生、每次入库都要动），两者混在一起会导致同一行数据频繁更新，锁竞争变严重，查询商品列表时也会因为无关的库存更新拖慢速度。

CREATE TABLE `stock` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `goods_id` BIGINT NOT NULL COMMENT '商品ID', `quantity` INT NOT NULL DEFAULT 0 COMMENT '当前库存数量', `locked_quantity` INT NOT NULL DEFAULT 0 COMMENT '锁定库存数量', `warning_line` INT NOT NULL DEFAULT 10 COMMENT '库存预警线', `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_goods_id` (`goods_id`) ) COMMENT='库存表';

至于订单表orders，我在命名和设计上特别注意了：订单不是"买了就完"，它需要记录完整的流转状态。我在表中加了一个order_status字段，用整型枚举来标识：待支付、已支付待发货、已发货、已完成、已取消、售后中。每个状态背后都有明确的业务含义，也有对应的操作触发条件。

3.2 库存流水表：追踪每一件商品的来龙去脉

只设计一张库存表其实是不够的，因为你只知道"现在库存是5"，但说不清这5是怎么来的。所以我还加了一张stock_flow库存流水表。

CREATE TABLE `stock_flow` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `goods_id` BIGINT NOT NULL COMMENT '商品ID', `change_type` TINYINT NOT NULL COMMENT '1-入库 2-销售出库 3-订单取消退回 4-盘点调整', `change_quantity` INT NOT NULL COMMENT '变动数量(正负)', `before_quantity` INT NOT NULL COMMENT '变动前库存', `after_quantity` INT NOT NULL COMMENT '变动后库存', `order_no` VARCHAR(64) DEFAULT NULL COMMENT '关联订单号', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_goods_id` (`goods_id`) ) COMMENT='库存流水表';

这张表的价值在系统上线后会体现得淋漓尽致。运营问"为什么这个商品库存对不上？"的时候，不再需要一个个查日志，直接按商品ID查流水，每笔变动的时间、类型、关联订单全部清清楚楚。这也是毕设答辩时可以重点讲的设计亮点——大部分学生的系统里根本没有流水表。

我还在库存表上设计了一个"锁定库存"的思路：用户下单但还没支付时，先把库存锁定，支付成功后才真正扣减；支付超时则释放锁定。这个逻辑直接避免了超卖问题，后面在并发部分会详细说。

4. 核心功能实现：商品、库存、订单三模块的落地细节

4.1 商品管理：上下架与分类的联动处理

商品管理听起来是纯 CRUD，但实际做的时候有细节门槛。第一个细节是商品编码goods_sn的唯一性校验。这个编码是给运营人员识别的编号，一旦重复，后面的库存单据、订单报表全都会串数据。我在接口层做了一件事：插入时先查一次是否存在；更新时排除自身判断。

// 更新商品时校验编码唯一性 LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Goods::getGoodsSn, goods.getGoodsSn()) .ne(Goods::getId, goods.getId()); if (goodsMapper.selectCount(wrapper) > 0) { throw new ServiceException("商品编码已存在，请检查后重试"); }

第二个细节是上下架联动库存判断。直接给一个"上架"按钮就行了吗？不行，库存为零的商品上架没有任何意义，只会带来无效订单。所以我在GoodsService的上架方法里做了这样的判断：查询库存数量，如果当前库存加锁定库存小于等于0，直接拒绝上架，并明确提示运营人员先补货。

第三个细节是分类的层级处理。零售商品分类经常是两级甚至三级的，比如"食品"下面有"休闲零食"，"休闲零食"下面还有"饼干"。如果直接存一个category_id，那点进某个叶子分类时想展示它上级分类的信息，就得反复查表。我的处理方式是冗余一个category_path字段（格式类似1,5,23），查询时直接IN查询该路径前缀的分类，一次搞定整条分类链。这种用空间换时间的思路，在后台列表页会显著降低查询复杂度。

4.2 库存管理：MySQL 事务与分布式锁的取舍

库存这块是整个系统里最容易翻车的地方，我强烈建议毕设里把并发扣减这个场景做出来，绝对是加分项。

最原始的做法是"先查库存，再扣减"，伪代码如下：

Integer quantity = stockMapper.getQuantity(goodsId); if (quantity >= 订单数量) { stockMapper.deduct(goodsId, 订单数量); }

这个代码在单人操作时没问题，一旦有两个用户同时下单，都读到了库存10，然后各自扣减5，最终库存变成5而不是0，这就产生了超卖。解决思路有两种。

• 乐观锁方案：在库存表里加一个version字段，扣减时带上版本号条件
• 悲观锁方案：查询时使用SELECT ... FOR UPDATE显式加行锁

我实际用的是悲观锁加事务的方式，因为在这个场景里库存行锁冲突的几率本身不高，FOR UPDATE 简单直接、可读性强。

@Transactional(rollbackFor = Exception.class) public void deductStock(Long goodsId, Integer count) { Stock stock = stockMapper.selectForUpdate(goodsId); if (stock == null) { throw new ServiceException("商品库存记录不存在"); } if (stock.getQuantity() - count < 0) { throw new ServiceException("库存不足，当前库存为 " + stock.getQuantity()); } stock.setQuantity(stock.getQuantity() - count); stockMapper.updateById(stock); // 同时写入库存流水 stockFlowService.record(goodsId, 2, -count, 原库存, 新库存, 订单号); }

这里我特意强调@Transactional必须指定rollbackFor = Exception.class，因为 Spring 默认只对 RuntimeException 回滚，如果业务代码里 throws 了一个自定义的受检异常，事务是不会自动回滚的，这点不知道坑了多少人。

另外要说的是，在毕设这种单机单体架构下，悲观锁FOR UPDATE已经足够应对"模拟并发扣库存"的演示场景了。如果想去讲分布式锁（Redis 分布式锁或者 Zookeeper 锁），那属于进阶内容，需要换分布式环境去讲，作为毕设主线反而容易讲得太散。把事务 + 行锁这套逻辑理清楚，再把库存流水补完整，已经是一个很扎实的设计。

4.3 库存预警与定时补货逻辑

库存预警是运营平台里特别能体现"系统智能感"的功能。实现思路并不复杂：在库存表里加一个warning_line预警线，然后定时任务去扫描所有库存量低于预警线的商品。

我实现时用了 Spring Boot 自带的@Scheduled注解，配置了一个 cron 表达式，每天早上九点跑一次：

@Component public class StockWarningTask { @Scheduled(cron = "0 0 9 * * ?") public void checkStockWarning() { List<GoodsStockVO> warningGoods = stockMapper.selectWarningList(); if (CollectionUtils.isEmpty(warningGoods)) { return; } // 组装预警消息，发送到管理员的待办通知 warningGoods.forEach(item -> { System.out.println("商品[" + item.getGoodsName() + "]库存不足，当前剩余" + item.getQuantity()); // 实际项目中这里可以短信/站内信提醒 }); } }

这段代码看起来简单，但我要补一句非常重要的细节：定时任务是跑在应用进程里的，如果你的后端是多实例部署（比如 Docker 起了两个容器），同一个任务会被触发两次。毕设环境单实例没问题，但如果以后做企业项目，就得考虑使用 XXL-Job 这类分布式任务调度，或者借助数据库锁表让同一时间只有一个实例真正执行。这个点可以作为拓展思路在答辩时提一句，显得你有全局视角。

4.4 订单管理：状态流转的闭环控制

订单模块是整条业务链路的消费端，也是状态最复杂的模块。我设计订单状态机的核心思想是：状态只能按预先定义的路径流转，不能随意跳转。

具体状态枚举定义如下：

代码层面，我在OrderService里写了一个transition方法，专门校验状态迁移的合法性：

private static final Map<Integer, Set<Integer>> STATUS_FLOW = new HashMap<>(); static { STATUS_FLOW.put(0, Set.of(1, 4)); // 待支付 -> 已支付或取消 STATUS_FLOW.put(1, Set.of(2, 4)); // 已支付 -> 发货或退款关闭 STATUS_FLOW.put(2, Set.of(3, 5)); // 已发货 -> 完成或进入售后 }

这个方法接收当前状态和目标状态，如果目标状态不在允许的集合里，直接抛异常。它最大的作用不是防用户，而是防开发自己脑子混乱——将来接手这个项目的人改代码时，看到这张状态流转表，一眼就明白每个状态和边界条件是怎么约定的，不再需要靠猜。

订单创建时还有一件事不能漏：必须关联写入库存流水。也就是前面代码里stockFlowService.record(...)那一行。没有这一步，库存数据就是一笔糊涂账，没法对账。我在这个模块里特意把订单号作为流水表的关联字段存了下来，以后想查"某个订单影响过哪些库存"就变得非常容易。

5. 前后端联调与部署：让系统真正能跑起来

5.1 前端路由与权限控制

前端我选择了 Vue + Element UI，主要看中它背靠成熟的组件生态，表格、表单、弹窗这些后台管理系统的高频组件都能快速搭建。页面结构上，我按左侧菜单 + 顶部面包屑 + 右侧内容区做了经典的后台布局，菜单项与后端接口的权限做了绑定。

权限这块如果只做"登录后才能看"是不够的。我设计了sys_user、sys_role、sys_menu三张表，管理员账号可以给不同角色分配不同菜单权限。操作员只能看商品和订单，财务角色还能看营收统计，这是典型的 RBAC 模型。前端在路由守卫里读取用户拥有的菜单权限，没有权限的菜单直接不渲染，后端接口也用拦截器做了二次校验。

// 前端路由守卫示例 router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token) { next('/login'); } else { // 校验路由meta上声明的权限是否在当前用户权限列表中 const perms = store.state.user.permissions; if (to.meta.permission && !perms.includes(to.meta.permission)) { next('/403'); } else { next(); } } });

这里要特别强调一个原则：前端的权限控制只是用户体验层面的优化，真正的安全校验永远要放在后端。前端隐藏了某个按钮不代表用户不能通过 Postman 直接调接口，所以后端每个涉及数据变动的接口都必须校验当前登录用户的角色权限。我在拦截器里统一处理了 JWT 的解析和权限判断，而不是在每个 Controller 里复制粘贴校验代码。

5.2 容易忽略的全局跨域与统一响应

前后端分离后第一个遇到的大坑就是跨域。前端跑在 8080 端口，后端跑在 8081 端口，浏览器默认禁止跨源请求。我直接在 SpringBoot 配置类里写了一个WebMvcConfigurer，配置允许的来源、请求头和请求方法。

@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); } }

注意我用的是allowedOriginPatterns("*")而不是allowedOrigins("*")。原因在于allowCredentials(true)开启后，Spring 不允许使用通配符配置allowedOrigins，但允许使用allowedOriginPatterns做模式匹配。这个细节在低版本 SpringBoot 2.4 以下还不存在，升级版本之后就会在这里卡一下，属于典型的"版本升级踩坑"。

统一响应结构也是我在项目一开始就定好的。所有接口都返回{ code, message, data }三段式 JSON，业务异常和系统异常分别返回不同的 code。前端接手时非常省心，拿到 code 不是 200 就直接弹 message，再不会出现"后端返回了一坨奇怪格式的报错，前端没法统一解析"的情况。

5.3 Docker 部署实践

毕设演示时最怕的就是"在我电脑上能跑，换台电脑就跑不起来"。为了解决环境一致性问题，我最终把系统用 Docker 容器化部署了。

我的部署规划是三个容器：MySQL 数据容器、后端应用容器、前端 Nginx 容器。用了 Docker Compose 编排，一条docker-compose up -d就能启动全部服务。

version: '3' services: mysql: image: mysql:8.0 container_name: retail-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: retail_platform ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql restart: always backend: build: ./backend container_name: retail-backend depends_on: - mysql ports: - "8081:8081" restart: always frontend: build: ./frontend container_name: retail-frontend depends_on: - backend ports: - "80:80" restart: always

在制作后端 Dockerfile 时，我给项目里的application.yml增加了多环境配置，本地用dev配置连接本机 MySQL，生产用prod配置连接容器内部的 MySQL。需要注意的地方是容器间通信不能用localhost，而要用 Compose 里的服务名，比如后端连接数据库的地址写的是jdbc:mysql://mysql:3306/retail_platform，这里的mysql就是 Compose 里的服务名。

Docker 部署这件事放到毕设里绝对是一个亮点。答辩的时候老师问"系统是怎么交付的"，你直接说"打包成镜像，目标服务器只需装一个 Docker 就能跑起来"，体感上完全不一样。

6. 实操中的性能优化与并发避坑

6.1 分页查询的性能细节

商品列表页和订单列表页的分页查询是整个系统里调用频率最高的接口，我注意到很多基础写法在这种接口上容易忽略性能细节。比如一次性select *查出所有字段再丢弃不用，或者列表页关联查询出每件商品的库存却又在循环里去单查数据库。

我这里做了两个优化。第一个是列表页的字段裁剪：只查询列表需要的字段，不查那些大文本字段（比如商品详情 description），等用户点开详情再读完整数据，能显著减少 MySQL 的 I/O 开销。第二个是避免 N+1 查询：商品列表需要展示商品分类名称和库存数量时，我先批量查出当前页商品ID列表，再一次性按这些 ID 查询分类和库存，然后在内存里组装数据。用一次联表查询替代了对每件商品各查一次数据库的做法。

// 批量查询库存，避免逐条查询的 N+1 问题 List<Long> goodsIds = goodsList.stream().map(Goods::getId).toList(); List<Stock> stockList = stockMapper.selectBatchIds(goodsIds); Map<Long, Integer> stockMap = stockList.stream() .collect(Collectors.toMap(Stock::getGoodsId, Stock::getQuantity)); // 遍历 goodsList 时直接 stockMap.get(goodsId) 拿库存

这种"批量查询 + 内存组装"的思路，是后端开发里非常高频且基础的优化手段。你把这个点写进代码注释里，面试官问"你做过什么优化"时就可以直接举它。

另一个关于分页的坑是 MySQL 深分页问题：偏移量越大，limit 100000, 10这样的查询会越来越慢。后台系统里常见做法是给列表页提供筛选条件，鼓励用户通过筛选缩小数据集范围。所以在订单列表页我特意做了按时间区间、商品编码、订单状态三个筛选维度，运营人员想找一条几个月前的订单，完全不需要翻到第几万条记录，直接按条件筛选即可。

6.2 并发场景值得关注的几个边界

刚才讲了库存扣减用 FOR UPDATE 解决并发超卖，但系统里不止一个并发场景，至少还有这几个边界值得考虑。

先说说订单超时未支付。如果用户下单后一直不付款，锁定库存就一直占着，影响其他用户购买。我的实现是用延迟任务定期扫描"超过30分钟未支付的订单"，自动改为已取消，同时释放锁定库存并回补可售库存。这里的核心逻辑是：状态变化的同时，库存也必须有对应变动，否则就产生"订单取消了，库存却没回来"的严重问题。

再一个边界场景是退款，用户支付后申请退款，后台同意前我要检查订单状态必须是"已支付待发货"或者"已发货"但未完成。如果已经发货了，一般走的是"退货退款"流程，状态要先进入售后中，不能直接从已支付跳到退款完成。这个判断在OrderService.transition的状态机里已经做了限制，所以我只需要保证调用顺序正确即可。

最后是超卖问题在"秒杀"这种极端场景下的处理方式。FOR UPDATE 能解决数字准确性问题，但场景再极端一些（比如只剩最后一件商品，几百人同时抢），行锁会引发大量线程排队。进阶的做法是先用 Redis 的原子递减预扣库存，真正落单时再校验数据库库存。这个属于高并发系统的玩法了，毕设里不做也行，但聊起来能体现你对问题边界的认识。

6.3 日志与链路追踪的重要性

业务系统上线后，最痛苦的问题就是"用户说他的订单出问题了，但开发不知道当时发生了什么"。我在这套系统里加了两个层级的日志保障。

第一层是接口访问日志，用拦截器统一打印每个请求的路径、方法、参数、耗时。这一层解决"用户到底调了哪个接口"的疑问。第二层是核心业务操作日志，比如商品上下架、订单状态变更、库存变动，都会以结构化格式写入日志文件。我在库存流水表、订单日志表里都做了落库保存。第一层解决"当时发生了什么"，第二层解决"业务数据为什么变成了现在这样"。

@PostConstruct public void init() { log.info("订单状态变更日志: orderNo={}, fromStatus={}, toStatus={}, operator={}", orderNo, oldStatus, newStatus, operatorName); }

对于单体毕设项目，我建议用 SLF4J + Logback 打印日志就足够，不推荐一上来就上 ELK 或 SkyWalking 全家桶。先把日志打到位、把流水记录好，将来真需要追查线上问题时，你才有底气说"这问题我能定位"。

7. 从题目到答辩：给毕设同学的核心建议

7.1 答辩演示的演示链路设计

很多同学代码写得很好，但答辩现场演示时却东点一下西点一下，考官看不出系统的完整逻辑。我的建议是设计一条"业务演示故事线"，把系统串起来讲。

我的演示流程是：先以管理员身份登录，展示权限控制的效果——普通操作员看不到库存预警菜单。然后录入一件新商品，设置价格和库存预警线，演示商品上下架操作。接着模拟用户下单，在订单列表里看到订单状态变为待支付，此时故意不支付，等待超时任务自动关单，再演示一次正常支付，然后发货、确认收货，让订单走完完整状态流。最后回到库存列表，展示这件商品的库存扣减流水，并演示触发预警线时的提示效果。

这条故事线的核心逻辑是"让每一张表和每一个接口都被串起来讲一遍"，考官顺着这条线路，能直观地看到系统各个模块是协同运转的，而不是一个个孤立页面的拼凑。

7.2 可以继续深化的方向

如果你的毕设做完基础功能后还有余力，我建议往这几个方向选一个做深度扩展。

• 数据可视化：引入 ECharts，在首页展示近七日销售额折线图、商品分类占比饼图、库存预警排行柱状图
• 商品批量导入：用 EasyExcel 支持运营人员从 Excel 批量导入商品数据，处理格式校验和错误反馈
• 验证码与行为校验：登录接口加入图形验证码，后台接口增加防重复提交机制
• 接口文档集成：引入 Knife4j 自动生成接口文档，答辩时直接展示 RESTful 接口的说明页面

我特别推荐第一个数据可视化方向，因为零售后台的运营场景天然适合图表展示，而且能让你用上 SQL 聚合查询（按月份GROUP BY统计销售额），内容完成度会明显提升。

7.3 回顾全文：这套系统的核心价值

整体讲完，你会发现这个项目表面上是一个 SpringBoot 后台系统，实际上它练的是你对业务链路的理解能力。商品模块考的是基础 CRUD 和字段设计；库存模块考的是并发控制、事务边界和流水追踪；订单模块考的是状态机的严谨性和异常场景处理。这三个能力恰好对应了后端开发最核心的"数据建模、并发安全、业务闭环"三件事。

如果非要给一个最小可行的落地顺序，我会建议你先把商品和库存的 CRUD 跑通，再补上流水表和并发扣减，接着做订单状态机，最后用 Docker 部署。这个顺序每完成一步，系统都是完整可用的，不会有任何一步是需要全部做完才能看到效果的尴尬状态。这样无论时间多紧，保证主链路始终是能演示的状态，整个项目就不会失败。