Spring Boot仓库管理系统实战：数据建模、并发扣减与权限设计-AI智能范式网

1. 立项背景：仓库管理系统为什么是Java练习项目的"标准答卷"

盘点你在Java路上反复绕不开的那几道坎

先说个现象：你打开任何一个Java学习交流群，十个人里有七八个都在背八股文，从JVM内存模型到Spring Bean生命周期，问起来头头是道。但只要你追问一句"你做过什么完整项目"，大多数人立刻卡壳。这个现象背后其实藏着一个很现实的问题——Java的学习资料太丰富了，反而让人一直停留在"看"和"背"的层面，很难真正动手把一个业务系统从零到一搭起来。

我见过太多这样的同学：Java基础学了三遍，Spring Boot入门教程刷了五六套，轮子造了一堆，但真要他独立做一套管理系统，他连表结构都设计不明白。不是他不懂技术，而是他缺一个"把技术串联起来"的业务场景。仓库管理系统恰恰是这个场景的最佳载体之一。

为什么很多人在仓库管理系统上"撞题目"

细心的读者会发现，"基于Java的仓库管理系统设计与实现"这个题目，在各大高校的毕业设计选题、课程设计任务书、培训机构的实战项目里反复出现。热度高不代表它简单，恰恰说明它是一个经过充分验证的"黄金选题"。

这里面有几个核心原因：

业务模型足够典型：仓库管理的核心就是"货物进出"和"库存变化"，这背后是标准的增删改查、状态流转、数据统计，和绝大多数企业级系统的本质一模一样。
技术覆盖度非常高：用户可以拆出权限管理，单据可以拆出主从表关联，库存可以拆出并发控制，报表可以拆出SQL聚合统计。一套系统做完，Java后端的主流知识点几乎全覆盖了。
需求可深可浅：它没有固定的"标准答案"。你可以只做最简单的单人操作版本，也可以做成多仓库、多角色、带审批流、带消息通知的完整版本。对初学者友好，对高手也有发挥空间。

我自己带过不少实习生和应届生，一个很直观的感受是：能把仓库管理系统做到"能上线"程度的人,整体工程素养都不会差。因为你会被迫去思考很多"教程里不会教"的问题，比如库存扣多了怎么办、物流单号重复怎么处理、一个仓库管理员误操作怎么追溯。

这套系统具体解决什么问题

回到业务本身。一个真实的仓库管理场景是什么样的？想象一家中小型贸易公司，代理了上百种商品，分布在三个仓库，每天有采购入库、销售出库、仓库间调拨、月度盘点这些动作。如果用Excel管理，会出现什么情况：

同一批货两个人同时登记，库存对不上；
出库单和实际发货数量不一致，月底算账时一团乱麻；
老板想知道"哪个商品积压最久""这个月哪个仓库出库量最大"，Excel根本答不上来。

所以，一个合格的仓库管理系统，核心要解决三个问题：账实一致（库存数据和实际货品数量对上）、流程可追溯（每一件货从哪来到哪去都查得到）、决策有依据（通过报表数据知道该补什么货、清什么仓）。本文后面讲的所有设计，都是围绕这三个核心诉求展开的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型：不要盲目追新，以稳定和够用为第一原则

后端框架：Spring Boot是绕不开的选择

仓库管理系统这种典型的业务系统，后端框架的选择其实没有太大悬念。Spring Boot已经是当前Java后端开发的事实标准，无论是毕业设计、个人项目还是中小型公司内部系统，它都是最优解。

这里说一下我为什么不太推荐还在用古老的SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）手写配置做这个项目。虽然有些学校教材还在教SSM，但从实际工程角度看，SSM的XML配置非常繁琐，而且和现代企业项目脱节严重。Spring Boot把自动配置、内置Servlet容器、起步依赖这些能力整合在一起，你关注业务本身的时间多得多。

关于版本，我个人的建议是：JDK用8或11，Spring Boot用2.7.x。除非你是为了简历上写"熟悉高版本"，否则没必要一上来就追JDK 17和Spring Boot 3.x。原因很简单：2.7.x的资料最丰富，遇到问题搜一下全是答案，而Spring Boot 3基于Jakarta EE，不少老教程的代码会踩坑。

持久层：MyBatis Plus比Hibernate更适合这个场景

持久层框架，我在MyBatis Plus和Spring Data JPA之间纠结过很长时间。最终建议用MyBatis Plus，理由有三点：

国内企业用MyBatis系的比例极高，面试时聊MyBatis不会吃亏；
MyBatis Plus提供了CRUD接口，基础增删改查不用写SQL，但复杂查询又允许你手写SQL精准控制，灵活性很好；
Hibernate的自动建表和懒加载机制对于初学者来说理解成本高，一旦遇到N+1查询问题，排错会很痛苦。

MyBatis Plus用起来基本就是继承一个BaseMapper<Entity>，然后selectById、selectPage这些方法就有了。比如：

java复制public interface StockMapper extends BaseMapper<Stock> {
    // 复杂查询可以在这里自己写SQL
    @Select("SELECT s.*, g.name AS goods_name FROM stock s " +
            "LEFT JOIN goods g ON s.goods_id = g.id " +
            "WHERE s.warehouse_id = #{warehouseId}")
    List<StockVO> selectStockList(Long warehouseId);
}

数据库选型与字符集的一处细节

数据库就选MySQL 8.x，这个基本没什么争议。但有两个细节值得单独说：

存储引擎必须用InnoDB：因为要支持事务。仓库管理里任何一个入库动作，都要求"单据生成"和"库存增加"要么同时成功、要么同时失败，MyISAM没有事务能力，直接排除。
字符集用utf8mb4，不要用utf8：MySQL的utf8是阉割版，最多存3字节，像emoji表情和部分生僻字存进去就会变成乱码或直接报错。创建数据库时写成：

sql复制CREATE DATABASE warehouse_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

前端方案：以毕业设计和实际落地为导向

前端这块是很多人最头痛的，因为纯后端开发者普遍不太擅长写页面。我的建议是分三种情况：

脱产学习或毕设需要快速出效果：用Vue 3 + Element Plus，前后端分离，接口用JSON交互。理由是Element Plus的表格、表单、弹窗组件非常成熟，做管理后台又快又好看。
只想专注后端、不想折腾前端工程化：直接用Thymeleaf模板引擎 + AdminLTE或Bootstrap模板，后端渲染HTML。这样部署简单，不需要写Vite（一种前端构建工具的配置）、也不用处理跨域。
如果你精力允许：我推荐前后端分离。因为面试时你可以在项目介绍里说一句"前端使用Vue + Element Plus，通过RESTful API与后端通信"，这比纯模板引擎听起来更像企业级项目。

项目分层与包结构

无论选什么框架，代码结构建议统一使用经典分层：

code复制com.example.warehouse
├── controller        // 接收请求，参数校验
├── service           // 业务逻辑，事务控制
├── mapper            // 数据访问层
├── entity            // 数据库实体
├── dto               // 前端交互对象
├── vo                // 视图返回对象
├── config            // 配置类（MyBatis、拦截器、跨域等）
├── common            // 公共返回类、异常处理、工具类
└── constant          // 常量定义

很多初学者把业务逻辑直接写在Controller里，这是一个非常不好的习惯。比如"入库"这个动作，如果直接在Controller里写死库存更新逻辑，那你测试、复用、加事务控制都会很麻烦。分层的目的不是多建几个包，而是让每一层各司其职，出了问题能快速定位。

3. 数据库建模：库存模型才是最考验设计功底的部分

主表设计：从"有什么实体"出发

一个标准的仓库管理系统，核心表我通常会分成四组。第一组是基础资料：goods（商品表）、warehouse（仓库表）、unit（计量单位表）、supplier和customer（往来单位表，看业务需不需要）。第二组是用户权限：sys_user、sys_role、sys_menu以及两张关联表。第三组是核心数据：stock（库存表）、stock_record（库存流水表）。第四组是单据：inbound_order和inbound_item、outbound_order和outbound_item，也就是主从表结构。

我们重点看商品表和库存表。商品表通常长这样：

sql复制CREATE TABLE goods (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    goods_code VARCHAR(32) NOT NULL COMMENT '商品编码',
    goods_name VARCHAR(128) NOT NULL COMMENT '商品名称',
    spec VARCHAR(64) COMMENT '规格型号',
    unit VARCHAR(16) NOT NULL COMMENT '计量单位',
    category_id BIGINT COMMENT '分类ID',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY uk_goods_code (goods_code)
) COMMENT '商品信息表';

注意goods_code加了唯一索引，这是真实业务的要求——同一家公司的商品编码必须全局唯一，否则Excel导入数据时会出现"同码不同名"的脏数据。

库存表的设计就更有讲究了：

sql复制CREATE TABLE stock (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    goods_id BIGINT NOT NULL,
    warehouse_id BIGINT NOT NULL,
    quantity INT NOT NULL DEFAULT 0 COMMENT '当前库存数量',
    locked_quantity INT NOT NULL DEFAULT 0 COMMENT '锁定数量',
    version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    UNIQUE KEY uk_goods_warehouse (goods_id, warehouse_id)
) COMMENT '库存表';

两个关键设计：唯一约束和锁库字段

先讲唯一约束。(goods_id, warehouse_id) 这个联合唯一索引是库存表的核心，它保证了"同一个商品在同一个仓库只能有一条库存记录"。这个约束的价值在于：如果没加它，并发情况下两条请求同时插入相同商品和仓库的记录，就会产生两行库存，后续怎么查都对不上账。

再讲locked_quantity字段。有些同学会问，库存表只要一个quantity不就够了吗？这里涉及一个电商仓库里面常见的"预占"场景：销售订单创建后，商品需要先锁定库存，等订单审核完成才真正扣减。如果只用一个字段，锁定状态和实际状态就混在一起了，销售和仓库两个部门的数据就说不清楚。所以我的建议是，库存分为"当前可用"和"锁定中"两个逻辑概念。当然，如果你的系统不涉及复杂的订单预占，只保留quantity也能用，但字段留在那里，扩展性会好很多。

流水表：保证"账实一致"的最后一环

流水表是整个系统追溯能力的来源，也是很多人容易漏掉的一张表。每一次库存变动，不管是入库、出库、盘点调整还是移库，都必须写一条流水记录。流水表设计如下：

sql复制CREATE TABLE stock_record (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    goods_id BIGINT NOT NULL,
    warehouse_id BIGINT NOT NULL,
    change_type TINYINT NOT NULL COMMENT '变动类型：1入库 2出库 3盘点调整 4移库出 5移库入',
    change_qty INT NOT NULL COMMENT '变动数量，正数为增加，负数为减少',
    before_qty INT NOT NULL COMMENT '变动前数量',
    after_qty INT NOT NULL COMMENT '变动后数量',
    ref_bill_no VARCHAR(64) COMMENT '关联单据号',
    remark VARCHAR(255),
    create_by BIGINT,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_goods_warehouse (goods_id, warehouse_id),
    INDEX idx_create_time (create_time)
) COMMENT '库存流水表';

关于流水表，我想多强调两句："变动前数量"和"变动后数量"这两个字段，宁可冗余也必须存。为什么？因为如果只存变动数量，一旦数据出错，你想回看"当时到底发生了什么"会非常痛苦。有了before和after，每一笔记录都能对账。

单据状态字段：用状态机管理流转

入库单和出库单这类数据，设计时一定要留一个状态字段。常用的状态机是：草稿（0）→ 待审核（1）→ 已审核（2）→ 已完成（3），另加一个作废（-1）状态。

这里有个经验之谈：不要用"删除"去处理审核后的错误单据。业务单据一旦生效，只能通过新增一张"红冲单"（反向单据）来冲抵，而不是物理删除。因为单据在财务对账、审计场景下是要保留痕迹的。这个思维和财务系统的"冲账"如出一辙。虽然仓库管理系统不一定需要做到财务级严格，但你具备这个意识，在面试时讲出来就是加分项。

4. 核心业务实现：入库、出库、调拨三条主链路

4.1 入库流程：先审单再入库，前后端状态同步

入库是整个系统里最简单的链路，但业务流程要梳理清楚。标准的入库流程是：

仓管员录入入库单，选择供应商、入库仓库；
在入库单下添加明细，可以选择商品、填写数量；
先保存为"草稿"，检查无误后提交审核；
审核通过后，系统增加指定仓库的商品库存；
写库存流水，关联入库单号。

这里有几个实现细节需要注意。第一，入库单和明细表必须放在一个事务里，保存主表拿到自增ID后，再循环保存明细；第二，审核动作必须校验明细是否为空、商品是否冻结，避免操作人员跳过必填信息；第三，入库操作要有幂等性判断——同一个入库单，不能因为网络抖动导致前端重复提交，就加了两次库存。解决幂等问题，最简单的方式是在入库单状态上加判断，只有"待审核"状态才能执行审核逻辑，审核后立刻改成"已审核"。前端如果重复点击，第二次请求拿到的单据已经是"已审核"了，程序直接拒绝。

核心代码大致如下：

java复制@Transactional(rollbackFor = Exception.class)
public void auditInbound(Long billId) {
    InboundOrder order = inboundOrderMapper.selectById(billId);
    if (order == null) {
        throw new BusinessException("入库单不存在");
    }
    // 状态校验，防止重复审核
    if (!OrderStatus.PENDING_AUDIT.equals(order.getStatus())) {
        throw new BusinessException("当前单据状态不允许审核");
    }
    List<InboundItem> items = inboundItemMapper.selectByBillId(billId);
    if (items.isEmpty()) {
        throw new BusinessException("入库单明细不能为空");
    }
    for (InboundItem item : items) {
        // 增加库存，这里调用库存服务
        stockService.increaseStock(item.getGoodsId(), order.getWarehouseId(), item.getQuantity());
        // 记录流水
        stockRecordService.record(item.getGoodsId(), order.getWarehouseId(),
                StockChangeType.INBOUND, item.getQuantity(), order.getBillNo());
    }
    order.setStatus(OrderStatus.AUDITED);
    inboundOrderMapper.updateById(order);
}

4.2 出库流程：防超卖比库存扣减本身更重要

出库的流程和入库类似，但最大的差别在于：出库是一个"减少库存"的动作，必须先校验库存是否充足，再执行扣减。很多初学者会把校验和扣减分成两步，先select查一次库存，判断quantity > 0，然后再update。这在单用户情况下没问题，但一旦多人同时操作，就会出大问题。

试想一个并发场景：仓库里某商品只剩1件，A和B两个销售员同时下出库单。A先查库存，看到是1件，通过校验；B同时也查库存，也看到是1件，也通过校验。然后A执行扣减变成0，B执行扣减变成-1。库存负数出现了，这就是典型的"超卖"。

正确做法是在SQL层面做条件更新，让数据库来判断：

java复制@Update("UPDATE stock SET quantity = quantity - #{qty}, version = version + 1 " +
        "WHERE goods_id = #{goodsId} AND warehouse_id = #{warehouseId} AND quantity >= #{qty}")
int deductStock(@Param("goodsId") Long goodsId,
                @Param("warehouseId") Long warehouseId,
                @Param("qty") Integer qty);

这条SQL的巧妙之处在WHERE条件里的quantity >= #{qty}。MySQL的更新操作默认会锁行，当两条并发更新到达时，数据库会让它们排队执行。第一条执行成功后，第二条更新时发现剩余库存已经不足，于是影响行数为0。我们在业务代码里判断返回的int结果：

java复制int rows = stockMapper.deductStock(goodsId, warehouseId, qty);
if (rows == 0) {
    throw new BusinessException("库存不足，扣减失败");
}

这一个动作就把"校验"和"扣减"合并成了原子操作，既避免了超卖，又避免了额外的一次查询。这是整个库存模块里最核心的经验，没有之一。

4.3 调拨与盘点：成对变动才能让账目平

调拨（移库）和盘点，是很多初学者容易设计崩掉的两个功能。

调拨的本质是"一减一加"：从A仓库出库，进入B仓库。这不只是简单调两个接口，而是要在同一次事务里完成"A仓库扣减"和"B仓库增加"，并且最好用同一张调拨单关联，方便追溯。拆成两步走最大的风险是：第一步成功，第二步失败，货从A仓库出去了但没到B仓库，账目就悬空了。用@Transactional包住整个流程，任何一个步骤抛异常，全部回滚。

盘点稍微特殊一点。盘点逻辑是"以实际盘点的数量为准，把系统库存调整为实物数量"。所以盘点单审核时，要计算差异：

java复制int diff = actualQty - currentQty;
if (diff > 0) {
    stockService.increaseStock(goodsId, warehouseId, diff);
} else if (diff < 0) {
    stockService.deductStock(goodsId, warehouseId, Math.abs(diff));
}

这里同样要记得写流水，变动类型标记为"盘点调整"。而且建议在盘点单上记录"账面数量"和"实盘数量"，方便后续复盘是仓库管理的问题还是系统数据的问题。

4.4 事务边界：一个"@Transactional"解决不了所有问题

业务代码里到处是@Transactional，但很多人对事务边界理解得比较模糊。入库、出库、调拨这类"多步写操作"必须加事务，这个没问题。但如果你在事务里做了耗时操作，比如调用第三方接口、发送短信、处理大文件，就要特别注意。

我的经验是：事务里永远不要做网络请求或IO操作。因为事务的本质是"占用数据库连接直到提交或回滚"，如果你在事务中间去调用第三方接口且对方响应很慢，数据库连接会被一直占用，连接池很快耗尽，整个系统就卡死了。正确的处理方式是：

事务内只做数据库相关操作；
把"发布消息、发通知"这些动作放到事务提交之后，可以借助TransactionSynchronizationManager.registerSynchronization回调事务提交后再执行。

java复制@Transactional(rollbackFor = Exception.class)
public void auditOutbound(Long billId) {
    // 核心业务逻辑...
    
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
        @Override
        public void afterCommit() {
            // 事务提交后，发通知或触发其他对外操作
            messageService.sendOutboundNotice(billId);
        }
    });
}

这个细节在实际工作中非常重要，但在很多教程里都不会讲，属于那种"代码能跑但不严谨，等在线上出问题才后悔"的典型。

5. 权限控制与统计报表：简历上最有分量的两个模块

5.1 RBAC权限模型：让"谁能干什么"一目了然

一个仓库管理系统，不可能所有登录用户都能操作所有功能。仓管员能录入入库单，但不能看财务数据；经理能看所有报表，但不能随便修改库存。这就是权限控制的用武之地。业界最经典的模型是RBAC（基于角色的访问控制），核心思路是：用户 → 角色 → 权限，通过角色把用户和权限解耦。

表结构上就是五张表：

sys_user：用户表，核心字段是用户名、密码、状态；
sys_role：角色表，比如"超级管理员""仓库主管""仓管员""只读用户"；
sys_menu：菜单/权限表，每个按钮、每个页面都可以对应一条权限记录；
sys_user_role：用户和角色的关联表；
sys_role_menu：角色和权限的关联表。

查询用户权限时，其实是个三表关联：

sql复制SELECT DISTINCT m.perms FROM sys_user u
JOIN sys_user_role ur ON u.id = ur.user_id
JOIN sys_role r ON r.id = ur.role_id
JOIN sys_role_menu rm ON r.id = rm.role_id
JOIN sys_menu m ON m.id = rm.menu_id
WHERE u.id = #{userId} AND m.perms IS NOT NULL

m.perms字段可以设计成类似warehouse:inbound:audit的字符串。登录成功后，把当前用户拥有的所有perms集合放入内存或Redis，后端写一个拦截器或AOP切面，每个需要权限的接口打一个@RequiresPermission("warehouse:inbound:audit")注解，拦截器里校验一下就完成了方法级别的权限控制。

5.2 登录鉴权：JWT + 拦截器就够用了

对于仓库管理系统，我建议用JWT做登录凭证，而不是传统的Session。原因主要有两个：

前后端分离时，Session方案要处理跨域Cookie问题，比较麻烦；
JWT是无状态的，后端不用存Session，水平扩展更方便。

实现逻辑是：用户登录成功后，后端生成一个JWT令牌，里面可以带上用户ID、用户名、角色信息，加上过期时间，返回给前端。前端放在请求头里，后端用一个拦截器解析令牌：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        String token = request.getHeader("Authorization");
        if (StringUtils.isBlank(token)) {
            throw new BusinessException("未登录或登录已过期");
        }
        // 解析token，如果过期或非法会抛异常
        Long userId = JwtUtil.parseToken(token);
        request.setAttribute("userId", userId);
        return true;
    }
}

然后在WebConfig里注册拦截器，并配置放行路径，比如/login接口不拦截，其他接口全部走拦截器。

有个小细节：JWT令牌不能存敏感信息，因为JWT的Payload部分只是Base64编码，不是加密的，任何人拿到令牌都可以解码看到内容。所以密码绝对不能放进去，用户ID和角色信息足够了。

5.3 统计报表：用SQL聚合代替逐行计算

仓库管理系统的报表模块，是让你在简历上写"熟悉复杂SQL"的关键素材。最常见的三个报表是：近30天出入库趋势、库存总量统计、低库存预警。

以"近30天出入库趋势"为例，原始数据在stock_record表里，要实现的是"按天分组、按类型统计数量"。SQL大概是这样的：

sql复制SELECT DATE(create_time) AS stat_date,
       SUM(CASE WHEN change_type = 1 THEN change_qty ELSE 0 END) AS inbound_qty,
       SUM(CASE WHEN change_type = 2 THEN ABS(change_qty) ELSE 0 END) AS outbound_qty
FROM stock_record
WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
GROUP BY DATE(create_time)
ORDER BY stat_date;

这个SQL用到了DATE()函数截取日期、CASE WHEN做条件聚合、DATE_SUB算时间范围。三种SQL技巧正好是面试时经常考察的点。

报表导出Excel可以用EasyExcel，这是阿里开源的库，API简单、内存占用低。一行代码思路：

java复制List<StockReportVO> list = stockService.getStockReport(warehouseId);
String fileName = "库存报表_" + System.currentTimeMillis() + ".xlsx";
EasyExcel.write(response.getOutputStream(), StockReportVO.class).sheet("库存报表").doWrite(list);

做报表时有几个坑要提前避开。第一，大数量查询别一次性select *全查出来再循环计算，尽量把统计逻辑交给SQL；第二，报表查询接口通常要加一个"时间范围不能超过X天"的限制，否则用户选个一年区间，查询可能慢得超时；第三，导出文件的流要记得关闭，否则文件被占用，下次导不出去。

6. 实测排坑：联调阶段最容易踩的三类问题

6.1 库存变成负数：并发扣减的完整排查链路

有次联调时，测试同学反馈"做了二十笔出库，库存变成-3了"。我当时第一反应是指出库流程里的"先查后改"问题。排查过程是这样的：

第一步，复现现场。让测试导出了操作日志，发现被扣成负数的商品在差不多同一秒内被下了多张出库单。

第二步，检查代码。果然出库的逻辑是"先select库存，判断数量够，再update扣减"。在单线程下这个逻辑没问题，但多线程下就出现了竞态条件。

第三步，修复方案。把"校验+扣减"合并成一条条件更新SQL，WHERE quantity >= #{qty}，通过影响行数判断是否成功。

修复之后，我又顺手干了一件事：在出库审核入口加了一个synchronized块，也就是在方法级别做并发控制。但当天晚上我自己就发现这个方法有问题——如果系统部署多台机器，synchronized只能锁住单台JVM，跨节点并发是锁不住的。最后真正靠的还是SQL层面的原子更新。这个排查链路特别典型，涉及"并发问题的表象、根因、假修复、真修复"四个环节，值得记下来。

6.2 事务不生效：方法自调用是个大坑

另一个高频问题是事务不生效。有个同学写的代码是这样的：

java复制public class OutboundServiceImpl {
    
    public void auditOutbound(Long billId) {
        checkStock(billId);
        deductStock(billId);
        recordLog(billId);
    }
    
    @Transactional
    private void deductStock(Long billId) {
        // 扣库存
    }
}

他以为deductStock加了@Transactional就万事大吉，结果运行后中途抛异常，库存照样被扣了，没有回滚。原因是Spring的事务是基于AOP的，只有外部调用代理对象的方法时，事务才会生效。而这里的auditOutbound和deductStock在同一个类里，是this直接调用，根本没有经过代理对象，所以事务注解完全被忽略了。

解决这个问题的方案有三种：

把事务方法拆到另一个Service类里，让OutboundServiceImpl调StockServiceImpl的方法；
在当前类注入自身代理@Autowired private OutboundService self;，然后调用self.deductStock(billId)；
用TransactionTemplate手动声明事务边界。

我最推荐第一种，不仅解决了自调用问题，还能让职责划分更清晰。排查这类问题最快的方式是启动日志：如果事务生效，Spring打日志时会有一句Creating new transaction，没有这句话，基本就是AOP没切到。

6.3 Lombok配置、日期精度与金额精度

在热搜词里能看到lombok will not work这类报错，这个我确实遇到过。同事用JDK 17，Lombok用的还是1.16老版本，一启动就报"使用不受支持编译器"的错。有些项目直接编译失败。解决办法是最小量的两件事：升级Lombok版本到1.18.30以上，或者在IDEA的Settings -> Build Tools -> Maven -> Runner里把"Delegate IDE build/run actions to Maven"勾上。更保险的方案是干脆不用@Data，手写Getter/Setter，避免版本兼容的麻烦，不过这个看个人取舍。

日期精度的问题出现在"出入库时间筛选"功能上。用户在页面上选了2024-05-01到2024-05-31，但后端查出来的数据少了5月31日当天。排查后发现是日期比较问题：前端传的结束时间是2024-05-31 00:00:00，那么23:59:59生成的记录自然查不出来。解决方式是对结束日期统一做处理，比如LocalDate解析后加一天，用小于次日零点的区间来查询。

金额精度相对简单，但也是老生常谈。商品的成本价、售价，千万不要用double或float，否则会出现1.1+2.2等于3.3000000000000003这种问题。数据库用DECIMAL(10,2)，Java实体用BigDecimal。涉及金额运算时，一律用multiply、add这些方法，且要指定MathContext。

7. 面试与简历：如何把这个项目讲出亮点

7.1 简历上的写法

如果你是应届生或转行者，这个项目的简历描述非常关键。不要写"负责仓库管理系统的开发，实现了商品的增删改查"这种流水账，而是要用项目背景 + 技术栈 + 个人职责 + 关键成果的结构。

举个例子：

code复制项目名称：基于Spring Boot的仓库管理系统（个人独立开发）
技术栈：Spring Boot + MyBatis Plus + MySQL + Redis + Vue 3 + Element Plus

项目描述：
针对中小型企业的多仓库管理场景，设计并实现了一套包含商品管理、库存管理、
出入库单管理、调拨盘点、权限控制和报表统计的Web系统，支持3个仓库并行使用。

个人职责：
- 负责数据库模型设计，共设计11张核心表，通过库存表和库存流水表分离，
  实现库存数据的可追溯性
- 基于RBAC模型实现用户角色权限控制，使用JWT完成无状态登录鉴权，
  配合拦截器完成接口级权限校验
- 通过"条件更新SQL + 受影响行数判断"解决并发场景下的库存超卖问题
- 使用EasyExcel实现报表导出，基于SQL聚合统计实现近30天出入库趋势分析

这样写的好处是，每一行都对应一个可深挖的技术点，面试官顺着任何一个点往下问，你都能讲出细节。

7.2 面试官高频追问的答题要点

围绕这个项目，面试官的问题通常集中在并发、事务、权限、数据库设计四个方向。我这里整理几个常见问题和一个简短的答题思路：

问题1：你的库存扣减是怎么防止超卖的？

这是一道送分题，但很多人会答歪。核心思路是：不能用"先查再改"，而是用UPDATE stock SET quantity = quantity - ? WHERE goods_id = ? AND warehouse_id = ? AND quantity >= ?，通过数据库行锁+条件更新保证原子性。可以再补充一句"如果数据量更大，且库存操作频繁，会考虑引入Redis预扣减+MQ异步落库，但复杂度会明显上升"，显示你有架构层面的思考。

问题2：你们的权限模型是怎么设计的？

回答要点：基于RBAC，用户关联角色、角色关联权限。权限细粒度到按钮级别，方式是在后端的权限接口方法上打注解，拦截器动态校验当前用户是否有对应权限标识。还可以补充"菜单表即权限表，通过得到用户的权限集合动态生成侧边栏菜单"。

问题3：如果出库单审核到一半，系统崩了，怎么保证数据一致？

这是一个典型的事务问题。答题思路：整个流程在了一个事务里，中间任何一步抛异常都回滚；如果服务宕机，数据库会自动回滚未提交的事务；如果担心审核后通知消息丢失，可以用事务同步器在事务提交后再发消息，或用本地消息表保证最终一致性。

问题4：库存流水表为什么不删？

这道题考察的是业务思维，不只技术。你可以说：流水表是"账实一致"的审计依据，任何库存变动都记录变动前后数量和关联单据号，遇到数据异常可以顺着流水反向对账；同时流水表也是报表统计的数据源。

问题5：如果以后商品量涨到百万级，库存查询变慢了怎么办？

数据库调优的进阶题。从索引角度说，库存表已经用了(goods_id, warehouse_id)唯一索引，查询走索引没问题；如果业务量大，可以把热点商品库存放进Redis；单据查询用分库分表，或者引入Elasticsearch做检索。关键是让面试官看到你能分层次、讲清楚不同方案的适用边界。

7.3 做完这个项目之后，还能往哪个方向扩展

仓库管理系统虽然是"经典题目"，但它和很多热门技术栈都能衔接上，这也是它常做常新的原因。做完基础版后，可以按这四步扩展：

引入Redis缓存：把商品列表、库存总量这些热点数据缓存到Redis，学习缓存穿透、击穿、雪崩的处理；
引入消息队列：出入库审核通过后发通知，改成RocketMQ或RabbitMQ异步处理，学习削峰填谷；
增加定时任务：用Quartz或XXL-JOB定时生成库存快照、自动清理过期单据，学习分布式调度的思想；
加一种设计模式：比如不同单据类型（入库、出库、调拨、盘点）用策略模式统一处理，这是面试常问的"策略模式多种组合"的实际落地。

每扩展一步，简历上就多一个可以深聊的亮点，也能让你从"CRUD工程师"往"设计者"的方向迈一步。

我个人做项目带人这几年，收到过很多次类似的反馈：很多人把八股文背得滚瓜烂熟，却连一个完整的库存扣减并发问题都答不好。原因就在于背的东西是"知识点"而不是"经验"，而经验只能在真实的项目场景里积累。仓库管理系统这个题目最迷人的地方在于，它不依赖任何花哨的业务背景，却能把Java后端开发里最核心的"事务、并发、权限、数据建模"全部过一遍。如果你正在学Java，不知道做什么练手，我真心建议你从这篇文章里的设计思路开始，把系统完整做一遍，然后用它去打磨简历、从容面试。你写下的每一行代码，都会成为下次回答面试官问题时，底气十足的那句话。

Spring Boot仓库管理系统实战：数据建模、并发扣减与权限设计