Java毕设仓库管理系统全攻略：Spring Boot+MyBatis进销存与库存设计

搞Java毕业设计选仓库管理系统，其实是个挺务实的选择。这个题目不冷门但也不至于烂大街，业务逻辑清晰，功能边界明确，往上可以加权限管理、报表统计，往下可以只做基础CRUD，伸缩空间很大，适合不同水平的同学拿捏。最关键的是，仓库管理系统背后的进销存逻辑，面试的时候经常被拿来当场景题考，做完这个项目，你简历上也有东西可写。这篇文章就围绕如何把这个毕业设计做出亮点、避开常见的坑、把论文写得像个正经研究来展开，尽量把我觉得有用的东西都说透。

1. 项目整体设计与需求拆解

很多同学拿到题目第一反应是上网找源码，这个思路没毛病，但直接拿别人的代码交差，答辩的时候一问就露馅。真正的做法应该是先搞清楚这个系统到底要做什么，把需求边界画清楚，然后才谈得上技术选型和代码实现。这是我认为整个毕业设计里最值得花时间的一步。

1.1 这个毕业设计到底做什么：核心业务流程和功能边界

仓库管理系统，说穿了就是管三件事：货进来、货出去、货待着。货进来对应采购入库，货出去对应销售出库，货待着就是库存管理。所有花里胡哨的功能都是围绕这三件事展开的，所以第一步必须把业务流程捋顺。

我建议你先把系统的角色拆出来。最常见的设计是两个角色：管理员和普通操作员。管理员拥有全部权限，包括用户管理、商品管理、供应商管理、入库审核、出库审核、库存调整、报表查看；操作员只能做日常作业，比如新建入库单、新建出库单、查看商品信息和自己的操作记录。这样一个简单的角色权限模型，既满足了业务需求，又能在论文里写“系统实现了基于RBAC的权限管理”，听起来就专业了很多。

功能模块上，我建议采用经典的五模块结构：

• 登录与权限管理：用户登录、会话保持、权限拦截。
• 基础资料管理：商品分类、商品信息、供应商信息、客户信息。
• 入库管理：创建入库单、明细录入、审核入库、记录入库流水。
• 出库管理：创建出库单、明细录入、库存校验、审核出库、记录出库流水。
• 库存与报表：库存查询、库存预警、出入库统计报表、操作日志。

这里有一个很重要的设计陷阱：不要一开始就想着做“高大上”的功能。比如自动补货算法、预测分析、扫码枪对接，这些功能要么涉及硬件，要么涉及机器学习，不是一个大作业周期能啃下来的。你做了反而容易在答辩时被追问细节，答不上来就是给老师送人头。MVP（最小可行产品）思路在毕设里同样适用，先把核心链路跑通，有余力再考虑扩展。

1.2 需求分析怎么做才不虚：用例图、流程图和功能清单

需求分析听起来像是一门玄学，但实际上就是让你把自己当作一个仓库管理员，想象每天上班要做哪些事。我自己做的时候是拿纸笔画的草图，把每个角色要做的事情列成一个清单，然后给每个功能标优先级（必须做、建议做、可选做）。

这个清单在写论文的时候会变成用例图（Use Case Diagram）和业务流程图。哪怕你代码写得一般，只要需求分析这一段逻辑清晰、图表规范，答辩老师都会觉得你的工程素养是过关的。所以需求分析阶段不要省，至少要在Word里画三个图：系统总体用例图、入库业务流程图、出库业务流程图。

功能清单方面，我给出一个可以直接用的版本：

我这个表格做出来之后，你的开发边界也就清楚了，不会写着写着跑偏。

2. 核心技术栈选型与理由

技术选型这件事，很多同学特别纠结，其实核心就是“用你熟悉的、能讲清楚的、不是特别老的组合”。仓库管理系统不是一个高并发的互联网应用，没必要上来就整微服务，也用不着Redis缓存和消息队列。选一个务实的技术栈，把它吃透，比堆砌一堆你只听过名字的框架强一百倍。

2.1 后端为什么是Spring Boot + MyBatis，而不是其他

Spring Boot作为当前Java后端开发的事实标准，选它没有争议。理由很简单：快速启动、约定优于配置、内嵌Tomcat、生态成熟。你只要在pom.xml里加依赖，写一个启动类，一个Controller就能跑起来，调试成本比传统的SSH（Spring MVC + Hibernate + 整合配置）低太多。

ORM层我推荐MyBatis，而不是JPA/Hibernate。原因有两个。第一，仓库管理系统的业务逻辑涉及大量动态SQL，比如多条件组合查询库存、统计报表里的按时间分组汇总，MyBatis的XML文件写这种SQL非常直观，你可以精确控制生成的SQL语句，出了问题也好排查；第二，面试的时候，MyBatis的动态SQL、一级缓存二级缓存、和Spring的整合原理，都是Java开发岗位的高频问题，你做毕业设计的同时把这些知识点吃透了，相当于一箭双雕。有同学会觉得MyBatis-Plus更好用，确实，MP提供的BaseMapper可以少写好多CRUD代码，但建议底层的SQL能力还是要有，论文里也最好提一句“本系统基于MyBatis框架实现了数据持久层的封装”，不要让人感觉你只会调MP的现成方法。

数据库层面MySQL没有悬念，免费、跨平台、资料多。需要提醒一点：不要用MySQL 8.0以下的版本。MySQL 5.7虽然还常见，但8.0的窗口函数、JSON类型、默认字符集utf8mb4，写起报表统计和特殊业务来方便得多。曾经一个学弟用了MySQL 5.6，字符集没设好，存中文直接乱码，浪费了一天时间排错。

2.2 前端技术选型：直接上Vue + Element UI，还是用模板引擎

前端的选择会直接影响你的开发效率和答辩观感。这里有两个方向：一是传统的服务端模板渲染，用Thymeleaf；二是前后端分离，用Vue + Element UI（或Element Plus）。

我个人强烈推荐前后端分离的方案，理由有三点。第一，现在主流公司不管大厂还是中小厂，前端分离已经是标配，你论文里明明白白写着“前后端分离架构，前端使用Vue框架，通过RESTful API与后端交互”，这在答辩的时候是加分的；第二，Element UI的表格、表单、弹窗、分页组件非常成熟，你只需要学会数据绑定和调用接口，一天时间就能把后台管理界面做出来，比用Thymeleaf手动拼HTML样式效率高得多；第三，Vue本身也是面试常客，你简历上写“熟悉Vue及Element UI组件库”，用人单位看了也不会反感。

如果对前端项目构建特别头疼，也不是没有退路：Vue项目可以用现成的后台管理模板，比如vue-element-admin，选一个精简分支，然后删掉不用的页面和路由，改成你的业务页面。这种做法在真实项目里也很常见，不是丢人的事。关键是你要能讲清楚Vue项目的目录结构、路由守卫、接口封装是怎么回事。

2.3 开发环境与版本锁定清单

版本不一致是Java开发最常见的坑之一，特别是JDK版本、Maven版本、Spring Boot版本之间的兼容关系。我自己在辅导学弟学妹的时候，总结了一张“版本锁定清单”，照着配基本不会出大问题。

关于JDK版本，我真的要多说两句。如果你选的是Spring Boot 3.x，千万别用JDK 8，否则启动直接报错；反过来Spring Boot 2.7配JDK 17，虽然能跑，但有一些兼容性警告，没特殊需要别这么干。JDK 8是很多老项目的主力版本，JDK 17是现在新项目的主流，两个版本对应的生态差别很大，网上搜资料的时候脑子里要清楚自己用的是哪一套组合。Maven的仓库镜像建议换成阿里云的镜像源，不然下载依赖的速度足够让你怀疑人生。

3. 数据库表设计与核心业务逻辑

数据库表设计是整个系统的地基，地基没打好，后面写Service层的代码就会特别别扭。很多同学喜欢一上来就建表，边写代码边改表结构，最后改得一团糟，逻辑也乱。正确的顺序是先画E-R图，理清实体之间的关系，再建库建表。这一步虽然费时间，但绝对是值得的。

3.1 核心表结构设计：从E-R图到物理建表

仓库管理系统涉及的核心实体包括：用户（User）、商品分类（Category）、商品（Product）、供应商（Supplier）、客户（Customer，可选）、入库单（InboundOrder）、入库明细（InboundOrderItem）、出库单（OutboundOrder）、出库明细（OutboundOrderItem）、库存（Stock）、操作日志（OperationLog）。

先画E-R图，梳理好关系再建表，关系明白了表就不会乱。然后物理建表，我给出每张表的关键字段和用途：

• sys_user（用户表）：id、username（唯一）、password（加密码加密，至少MD5或BCrypt）、real_name、role（admin或operator）、status（启用/禁用）、create_time。用户表不用设计得太复杂，不要搞什么部门表、角色表、菜单表，那是一个完整的权限系统该做的事，毕设项目做简单的角色字段就够用了。

• product_category（商品分类表）：id、category_name、parent_id（支持两级分类）、sort_order。如果觉得两级分类没必要，可以直接做平铺列表，每行一个分类。

• product（商品表）：id、product_code（商品编码，唯一）、product_name、category_id、specification（规格）、unit（单位，如箱/件/袋）、safety_stock（预警库存）、create_time、update_time。商品编码建议用纯数字或字母数字组合，不要用中文。

• supplier（供应商表）：id、supplier_name、contact_person、phone、address。可选字段，但如果入库单要关联供应商，这张表就得有。

• inbound_order（入库单主表）：id、order_no（入库单号，唯一，建议日期+随机数生成）、supplier_id、total_quantity、status（待审核/已审核/已作废）、create_by、create_time、audit_by、audit_time、remark。

• inbound_order_item（入库单明细表）：id、order_id、product_id、quantity、unit_price。注意：一个入库单对应多条明细，明细是跟着主表走的，主表审核通过时，明细里所有商品一起加库存。

• outbound_order（出库单主表）：字段结构类似入库单主表，status多了“库存不足”的校验逻辑。

• outbound_order_item（出库单明细表）：id、order_id、product_id、quantity。

• stock（库存表）：id、product_id（唯一）、quantity、update_time。这张表看似简单，但实际业务里有个大坑，就是库存扣减的时机，后面我会重点讲。

• operation_log（操作日志表）：id、operator_id、action、detail、operate_time。日志表建议记录“谁在什么时间做了什么”，比如“张三审核了入库单IB20250601001”，这对答辩时的演示很有帮助。

3.2 库存扣减逻辑：为什么不能简单粗暴地“改库存”

这是整个系统里最核心的业务逻辑，也是答辩时最容易翻车的地方。新手常见的写法是：出库单审核通过时，直接写一条UPDATE stock SET quantity = quantity - #{num} WHERE product_id = #{id}。看起来没问题，但仔细一想，这里至少有四个隐患：

第一，没有库存校验。如果库存只剩10件，有人出库了20件，直接减就变成负数了，这在真实业务里是不能接受的。第二，没有考虑并发操作。两个操作员同时提交出库单，如果都通过了库存校验，然后同时执行减库存，数据库的隔离级别较低时可能把库存减出负数。第三，没有库存流水。一旦库存数不对了，或者想查“某段时间的入库总量”“某个商品的出库去向”，你无从查起。第四，业务上说不通。操作员点一下审核，库存就变少了，这个“减少”的依据是什么？数据审计怎么做？

正确的做法是引入“流水驱动库存”的设计思想：真正的数据源头是inbound_order_item和outbound_order_item这两张流水明细表，stock表只是一个“冗余缓存”而已。任何库存变动都先判断流水是否合理（出库时检查累计出库量是否大于累计入库量），再决定是否写流水，最后由一个服务方法按商品汇总流水来刷新库存表。

伪代码逻辑是这样：

java复制@Transactional(rollbackFor = Exception.class)
public void auditOutboundOrder(Long orderId) {
    // 1. 校验订单状态，防止重复审核
    OutboundOrder order = outboundOrderMapper.selectById(orderId);
    if (order == null || !"PENDING".equals(order.getStatus())) {
        throw new BusinessException("订单不存在或状态不允许审核");
    }

    // 2. 遍历明细，检查每个商品的可用库存
    List<OutboundOrderItem> items = outboundOrderItemMapper.selectByOrderId(orderId);
    for (OutboundOrderItem item : items) {
        Integer stock = stockMapper.selectQuantityByProductId(item.getProductId());
        if (stock == null || stock < item.getQuantity()) {
            throw new BusinessException("商品库存不足：" + item.getProductId());
        }
    }

    // 3. 先写流水明细，再更新库存（同一事务内）
    for (OutboundOrderItem item : items) {
        outboundStockRecordMapper.insert(item);
        stockMapper.decreaseStock(item.getProductId(), item.getQuantity());
    }

    // 4. 更新订单状态
    order.setStatus("AUDITED");
    outboundOrderMapper.updateById(order);
}

这里的@Transactional(rollbackFor = Exception.class)特别重要。默认情况下Spring的事务只对RuntimeException回滚，如果你抛的是自定义Exception，不加rollbackFor，事务就不会回滚，会出现流水写了但订单状态没变的“中间态”。这个知识点在面试里也经常考。

另外，如果你的库存校验和扣减是在同一个事务里做的，InnoDB的行锁会保证同一时刻只有一个事务能操作同一个商品的库存，不会出现并发超卖。不需要额外加分布式锁，因为这里根本用不上。

3.3 批次与保质期管理：拉开档次的高级设计

如果做完基础版本还有时间，我强烈建议加上“入库批次（Batch）”的概念。真实的仓库里，同一款商品不同批次的进价、生产日期、过期日期可能是不同的，如果不做批次管理，你只能把商品当成一个无差异的整体，这在生鲜、医药、食品行业是行不通的。

最简单的批次设计：在入库明细表里加batch_no（批次号）、production_date、expire_date字段，同时在stock表里改成“按商品+批次维度存储”，即一张库存记录代表某个商品某个批次的剩余数量。出库的时候优先选择过期日期早的那一批，这就是“先进先出（FIFO）”的库存策略。

这个设计一旦做出来，论文的“系统创新点”和“数据库设计亮点”就有内容写了。答辩老师如果问“你的系统怎么处理临期商品？”你就可以很从容地说：“本系统为商品管理引入了保质期和批次维度，支持临近过期商品预警，出库时遵循先进先出原则”。这句话的分量，比你写十页需求分析都管用。

4. 核心功能实现要点与实操过程

前面把设计层面的东西理清楚了，这一节落到代码上。我会按“登录权限 -> 入库审核 -> 分页查询 -> 报表统计”这条主线来拆，每段的代码都不长，重点是讲清楚为什么要这么写。

4.1 登录与权限拦截：从过滤器到拦截器的一次完整实现

登录功能看似简单，但涉及到会话管理、密码加密、权限控制三个点，每一步都有坑。

密码加密我建议用Spring Security自带的BCryptPasswordEncoder，不要用MD5。MD5虽然快，但现在已经很容易被彩虹表撞库破解，而BCrypt是带盐的哈希算法，每次加密结果都不一样，即使两个用户密码相同，密文也不同。你只需要在pom.xml引入spring-security-crypto这个依赖，然后注入BCryptPasswordEncoder即可。

登录接口的逻辑：接收用户名和密码，从数据库查用户，比对BCrypt密文，如果通过就生成一个Token（可以使用JWT，也可以使用UUID存储在Redis里，但为了简单起见，直接用JWT更合适），把用户ID和角色信息放进Token，返回前端。

前端拿到Token后，每次请求在请求头加Authorization: Bearer 。后端用一个拦截器每次请求时解析Token，把请求放行或者返回401。核心代码如下：

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 放行登录请求
        if ("/api/auth/login".equals(request.getRequestURI())) {
            return true;
        }

        String token = request.getHeader("Authorization");
        if (token != null && token.startsWith("Bearer ")) {
            token = token.substring(7);
            Claims claims = JwtUtil.parseToken(token);
            if (claims != null) {
                // 把用户信息放入ThreadLocal，后续Controller可以直接获取
                UserContext.setUserId(claims.get("userId", Long.class));
                UserContext.setRole(claims.get("role", String.class));
                return true;
            }
        }
        response.setStatus(401);
        return false;
    }
}

记得在WebMvcConfigurer注册拦截器，并把静态资源和登录接口放行。

权限控制上，管理员能调用的接口（比如用户管理、审核入出库）可以在方法上做一个简单的注解或者直接判断UserContext.getRole()。不用引入Spring Security那一整套，那样反而把问题搞复杂了。

4.2 入库单审核的事务边界：为什么会在一个方法里嵌套多个操作

入库单审核这个功能，是整个系统里最复杂的业务闭环，它牵涉到多张表的联动操作。我在代码里给它定义一个完整的“事务边界”：

java复制@Transactional(rollbackFor = Exception.class)
public void auditInbound(Long orderId, Long auditorId) {
    InboundOrder order = inboundOrderMapper.selectById(orderId);
    if (order == null || !"PENDING".equals(order.getStatus())) {
        throw new BusinessException("入库单不存在或已审核");
    }

    List<InboundOrderItem> items = inboundOrderItemMapper.selectByOrderId(orderId);
    if (items.isEmpty()) {
        throw new BusinessException("入库单明细为空，无法审核");
    }

    // 累加库存
    for (InboundOrderItem item : items) {
        Stock stock = stockMapper.selectByProductId(item.getProductId());
        if (stock == null) {
            // 首次入库需要新建库存记录
            stockMapper.insert(new Stock(item.getProductId(), item.getQuantity()));
        } else {
            stockMapper.increaseStock(item.getProductId(), item.getQuantity());
        }
    }

    order.setStatus("AUDITED");
    order.setAuditBy(auditorId);
    order.setAuditTime(new Date());
    inboundOrderMapper.updateById(order);
}

这个函数里做的事情很多：查订单、校验状态、查明细、改库存、更新订单状态。这五个操作必须是一个原子操作，要么全成功要么全失败。如果中间某一步出错了，比如第3个商品加库存时数据库有问题，前面的库存修改已经提交了，订单状态却没更新，就出现了严重的数据不一致。所以一个事务把所有操作包起来，任何一个RuntimeException都会让整个事务回滚，数据库回到执行前的状态。

有个小细节：事务控制一般在Service层，不要在Controller层加@Transactional。因为一个Controller可能调用多个Service方法，每个Service方法的事务粒度应当由Service自己控制，Controller只负责接收参数和返回结果。

4.3 分页与条件筛选：写一个通用查询接口的思路

后台管理系统的列表页基本都有分页加多条件筛选的需求。如果你用的MyBatis-Plus，分页非常简单，直接用Page对象加LambdaQueryWrapper就行。如果你用的是原生MyBatis，需要引入PageHelper插架，用法是：

java复制PageHelper.startPage(pageNum, pageSize);
List<Product> products = productMapper.selectProductList(conditions);
PageInfo<Product> pageInfo = new PageInfo<>(products);

需要注意的是，PageHelper.startPage必须紧跟着执行第一条SQL的Mapper方法，中间不能有任何别的SQL操作，否则分页会不生效或者分页错乱。这是PageHelper最容易踩的坑。

条件筛选我建议在ProductMapper.xml里写动态SQL，核心片段如下：

xml复制<select id="selectProductList" resultType="com.example.entity.Product">
    SELECT * FROM product
    <where>
        <if test="productName != null and productName != ''">
            AND product_name LIKE CONCAT('%', #{productName}, '%')
        </if>
        <if test="categoryId != null">
            AND category_id = #{categoryId}
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

为什么写动态SQL而不直接拼字符串？因为拼字符串有SQL注入风险，而MyBatis的#{}预编译可以避免这个问题。另外这里用CONCAT而不是'%${productName}%'，也是为了避免${}直接拼接导致的注入风险。

4.4 报表统计接口：给论文加分的可视化数据是怎么来的

仓库管理系统如果只做CRUD，答辩的时候老师会觉得你只是做了一个“增删改查系统”，没有什么技术难度。加上报表统计模块，整个项目的档次就上来了。报表不建议做特别复杂的，一个折线图就够了：近30天每日入库量和出库量。

后端SQL逻辑是：

sql复制SELECT DATE(create_time) AS day, COUNT(*) AS cnt
FROM inbound_order
WHERE status = 'AUDITED' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 29 DAY)
GROUP BY DATE(create_time)

需要注意，SQL的日期函数在不同数据库有差异，比如MySQL用DATE_FORMAT，PostgreSQL用TO_CHAR。我们既然选了MySQL 8.0，就统一用DATE_FORMAT写。如果查询不到数据，或者日期分组不连续，可以在Java端做一次“补零”处理，把缺失的日期补成0，不然前端画出来的折线图是断的。

前端展示用ECharts，把接口返回的日期数组和数量数组塞进去，就是一个很漂亮的趋势图。这一功能在论文里可以作为“系统测试与结果分析”的截图素材，也能在演示环节用来引导老师提问，展示效果拉满。

5. 毕业设计论文怎么写才不像“糊弄”

代码写完只是完成了一半，论文在评分里占比往往是30%~40%，甚至更高。很多同学代码写得还凑合，论文却写成了“需求说明书的复读机”，这是很可惜的。这里分享一些写论文的实战经验。

5.1 论文大纲与各章节占比的建议

毕业设计论文虽然没有统一的铁标准，但基本遵循一个套路：摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结与展望。我建议按以下字数比例来分配：

• 摘要：300字左右，中文摘要加关键词。
• 第一章 绪论：约10%。写研究背景、国内外研究现状、主要工作。背景不要抄百度百科，要结合着写，比如“随着电商行业的快速发展，中小型仓库的库存数据越来越复杂，传统Excel记账方式存在数据冗余、实时性差等问题”。
• 第二章 相关技术介绍：约15%。写Java语言、Spring Boot框架、MyBatis框架、Vue框架、MySQL数据库。每个技术1~2页，别写太长，这里不是重点。
• 第三章 需求分析：约20%。写可行性分析、用例图、角色分析、功能需求、非功能需求。这一章要放图和表。
• 第四章 系统设计：约25%。写系统架构图、功能模块设计、数据库E-R图、数据表结构设计。这是核心章节，图表密度要高。
• 第五章 系统实现：约20%。按模块写实现思路，贴关键代码截图或代码片段，配合界面截图。注意不要全文贴代码，只贴核心代码。
• 第六章 系统测试：约10%。写测试环境、测试用例表、测试结果分析。
• 第七章 总结与展望：5%以内。写做了什么、还有什么不足。

这个结构是很标准的，老师一看就觉得你懂论文怎么写。

5.2 画图技巧：用例图、流程图、E-R图怎么画才专业

论文里的图是印象分的重要组成部分，图丑等于自降等级。不要用Windows画图板手画，也不要粘贴网上来源不明的图。推荐两个工具：ProcessOn和draw.io，都支持导出矢量图，也可以直接用PlantUML写代码生成UML图。

用例图（Use Case Diagram）要画出角色和用例之间的关系。比如“操作员”可以关联“登录系统”“创建入库单”“创建出库单”“查询库存”，“管理员”除了继承操作员的用例还能关联“用户管理”“审核入库单”“审核出库单”。这张图放在第三章需求分析里。

流程图重点画两个：入库流程和出库流程。入库流程：创建入库单 -> 填写明细 -> 提交审核 -> 审核通过 -> 增加库存 -> 记录流水。出库流程：创建出库单 -> 填写明细 -> 提交审核 -> 校验库存 -> 扣减库存 -> 记录流水。注意分支判断要用菱形框表示，审核不通过要走“驳回”分支。

E-R图建议用实体关系图来表达。不需要把所有字段画出来，画出实体名、主键和核心外键关系就够了。关键是实体之间的关系标注要清楚，比如商品到入库明细是1对N，入库单到入库明细也是1对N，商品到库存是1对1，这些关系对不上会被老师挑刺。

5.3 测试章节怎么写才充实：测试用例表制作方法

系统测试章节最忌讳写“功能正常”“运行正常”这种空洞的描述。要设计一份测试用例表，格式大概是：

测试用例通常写15~20条，覆盖正常流程、异常流程和边界情况，比如库存为0时出库、用户名超长、重复提交审核。边界情况的用例最能体现你的测试思维，一定要写。

5.4 答辩现场的5个高频问题与应对思路

答辩时老师大概率不会把你代码从头到尾看一遍，而是通过提问来判断这个项目是不是你做的。提前准备这5个问题，基本能稳住阵脚。

第一个问题：“请简述一下你的系统架构。”应对思路：讲清楚前后端分离、后端分层架构（Controller-Service-Mapper）、数据库MySQL，以及请求的流程。不要背概念，用一句话串联起来，比如“用户在前端登录后，前端把用户名密码发给后端Controller，Controller调用Service层处理业务逻辑，Service调用Mapper层访问数据库，返回结果再逐层传回前端”。

第二个问题：“你的库存扣减是怎么保证并发安全的？”应对思路：从事务和行锁的角度回答，说明使用了数据库事务，MySQL InnoDB引擎在更新同一行时会加行锁，保证同一时刻只有一个事务能修改该商品的库存。

第三个问题：“为什么选择MyBatis而不是JPA？”应对思路：结合动态SQL优势来回答，顺便说说MyBatis和JPA的适用范围和取舍。

第四个问题：“前端是怎么和后端交互的？”应对思路：讲RESTful API设计、HTTP方法、JSON数据格式，以及axios请求封装和拦截器。

第五个问题：“系统的安全性怎么考虑？”应对思路：从密码加密（BCrypt）、Token鉴权、SQL注入防护、参数校验四个方面回答。

6. 常见问题与避坑实录

最后这一节，我把自己和身边朋友做项目时踩过的、以及在网上看到的高频问题整理出来。这些问题如果你遇到了，照着做基本都能解决。

6.1 编译期“源发行版17需要目标发行版17”报错

这个问题出现的场景是：你在IDEA里设置了JDK 17，但Maven的pom.xml里maven.compiler.source和maven.compiler.target还没跟上，或者IDEA的Project Structure里Project SDK是17，但Java Compiler里Target bytecode version还是8。解决办法是打开pom.xml，确保下面是版本一致：

xml复制<properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <java.version>17</java.version>
</properties>

如果用的是Spring Boot父级POM，<java.version>会自动同步到maven.compiler.source/target，改这个属性就够。改完后在IDEA里执行一遍mvn clean compile，多按几次刷新，别让IDEA的缓存继续报旧错误。

6.2 Lombok报错：you aren't using a compiler supported by lombok

这个问题的核心是：IDEA里装了Lombok插件，但项目用的是新版本JDK编译，Lombok版本太老，无法识别当前JDK的编译器。解决办法：第一，升级Lombok依赖到最新版（1.18.30以上）；第二，确认IDEA的Java Compiler设置里，把Annotation Processors（注解处理器）勾上；第三，试试在Maven的pom.xml里加上：

xml复制<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.30</version>
    <scope>provided</scope>
</dependency>

如果版本号已经是新的但还报错，去IDEA的Plugins里看看Lombok插件是否启用，重启IDEA基本上能解决。

6.3 Maven或运行时OutOfMemoryError: insufficient memory

这个问题有三个场景，场景不同处理方式不同。编译期报内存不足，在Maven的VM Options里调整，比如在IDEA里打开Settings -> Build Tools -> Maven -> Runner，在VM Options里填入-Xmx1024m。运行期报内存不足，在运行配置的VM options里加-Xms256m -Xmx1024m。如果是因为本地同时开了太多东西（IDEA、Chrome、MySQL、微信），把不用的应用关掉再试。说到底，毕设项目的内存需求没那么大，大部分都是环境配置问题而不是性能问题。

6.4 端口占用导致Spring Boot启动失败

启动报Port 8080 was already in use，说明8080端口被别的进程占了。先查是哪个进程占用的：Windows下用netstat -ano | findstr 8080，然后在任务管理器里结束对应PID，也可以用IDEA的Terminal执行taskkill /PID /F。不想杀进程的话，就在application.yml里换一个端口，比如server.port=8081。

这里提醒一点：前后端分离项目，前端Vue默认跑在8080，后端Spring Boot也默认8080，比较容易冲突。建议统一约定：后端用8080，前端用8081，或者反过来。这个细节写在论文的系统配置说明里，显得你很细心。

6.5 数据库中文乱码和时区问题

中文乱码是最能消磨耐心的问题，根源99%是字符集不一致。第一步，建数据库时指定字符集utf8mb4，DLL语句写成：

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

第二步，在Spring Boot的application.yml的数据库连接URL上加上参数：

yaml复制url: jdbc:mysql://localhost:3306/warehouse_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai

第三步，如果表已经建好了但数据乱码，把表和字段的字符集也改成utf8mb4。时区问题一般在JDBC连接串加上serverTimezone=Asia/Shanghai就能解决，不然你会看到时间差8小时的诡异现象。

6.6 一个容易被忽略的坑：前端跨域问题

前后端分离项目，前端页面跑在localhost:8081，后端接口在localhost:8080，直接请求一定会遇到CORS跨域拦截报错。解决方式是后端写一个CORS配置类，允许指定来源的跨域请求：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:8081")
                .allowedMethods("*")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

如果用了JWT拦截器，注意拦截器的顺序要保证OPTIONS预检请求能正常放行，否则跨域请求会被卡在401，这个坑我调试过整整一个下午。解决办法是在JwtInterceptor的preHandle里加一个判断：如果是OPTIONS请求，直接返回true。

仓库管理系统这个题目，说简单也简单，说复杂也能复杂。你把技术栈选稳当、数据库设计理清楚、库存逻辑真正想明白，代码量其实不算大，真正花时间的反而是设计和调试。我个人在实际做的时候体会最深的一点是：宁可少做几个功能，也要把已经做的功能做到逻辑闭环。一个能讲清楚“为什么这么设计”的CRUD，比一个说不出原理的复杂系统更能拿到好分数。最后再分享一个小技巧，答辩前自己按照角色权限把整个流程走三遍，把每一步操作对应的代码位置和数据库变化都标记出来，这样不管老师问到哪一步，你都能快速接招，稳住现场。