Spring Boot+MySQL粮库管理系统：源码、部署与毕业设计实战

每年三四月份，来找我改Java毕设的人特别多，其中一半以上的问题都是同一个：想做一个Spring Boot + MySQL的题目，还要有现成源码能参考，最好文档也齐全，能直接跑起来。今天聊的这个粮库管理系统，正好踩中这个需求——基于Java + Spring Boot + MySQL，同时覆盖粮仓管理和粮库设备管理两条业务线，标题后面还挂着“附源码+文档，调试定制服务”。我最近帮人完整复现过并跑通过这套项目，下面把从选题价值、技术拆解到部署调试的整个过程梳理一遍。

1. 这个毕设题目为什么值得选：粮库系统的业务边界与答辩亮点

1.1 粮仓管理加设备管理的双主线结构

很多人选毕设题目的时候有个误区，觉得功能越多越好。实际上对Java Web类项目来说，最怕的不是功能少，而是业务散。图书管理、购物商城这类题目虽然常见，但答辩老师问几轮就聊不出新东西了。粮库管理系统不一样，它天然有两条业务线：一条是粮仓里的粮食库存管理，另一条是粮库配套设备的管理。这两条线彼此独立又有业务关联，拆开可以做两个题目，合在一起就是一个完整性很强的综合系统。

从实际项目中看，粮库里的业务流程大概是这样的：粮食进来先登记入库单，记录粮食品种、数量、来源、对应仓房；仓房里的库存会随着出入库动态变化；粮库会用到通风设备、温湿度传感器、输送机、除尘设备等，这些设备需要建立台账，还要定期保养。这样的业务逻辑放到系统里，就是“入库登记—库存台账—出库登记—仓房管理”加“设备档案—保养计划—保养记录”。每个环节都是真实业务，讲起来不空洞，画E-R图、用例图也都有素材。

1.2 站在答辩角度拆解需求，能讲清楚比功能多更重要

我经常跟同学们说，答辩的时候你不需要把每个按钮都讲一遍，但必须把核心业务的完整闭环讲清楚。拿这套粮库系统举例，最该讲清楚的闭环有两个。

第一个是粮食出入库闭环：入库单提交后，库存数量增加；出库单提交后，库存数量减少；库存台账记录当前各仓房的实时存量。这中间涉及到一个关键设计问题——不能用“一进一出”两张表就完事，还得考虑流水可追溯。你在答辩时能说清楚“流水表保存历史，库存表保存最新状态，出库时校验库存是否充足”，这就是一个很好的加分点。

第二个是设备保养闭环：设备档案里记录每台设备的安装日期、保养周期，系统根据下次保养日期判断是否临近保养，生成提醒列表；维护人员填写保养记录后，更新下次保养时间。这个闭环逻辑简单但很合适，因为它能演示出你对“业务状态流转”的理解，而不是停留在一堆CRUD页面上。

1.3 功能清单与角色权限设计建议

一套完整的粮库管理系统，在毕设层面做这些功能就够了：

角色权限不一定要做得很重，Spring Boot下可以基于拦截器实现简单的登录校验和角色判断。如果源码里用了Spring Security，也可以直接用注解@PreAuthorize控制接口权限。个人建议非必要不引入太重的安全框架，能跑通、能讲清楚权限控制思路才是重点。

2. Spring Boot + MySQL 的选型逻辑与项目初始化

2.1 为什么这个技术组合是当前毕设的标准答案

现在回看Java Web的发展，SSH已经是历史，SSM也慢慢退出主流课堂，Spring Boot几乎成了所有Java后端岗位和课设项目的默认选择。它和MySQL搭配的核心优势有三个：一是自动配置极大减少了配置文件量，写个application.yml就能启动；二是生态成熟，无论是模板引擎还是ORM框架，找资料都非常方便；三是就业市场认可，面试官看到Spring Boot项目至少不会觉得技术栈过时。

MySQL方面，粮库库存数据明显是结构化的关系型数据：仓房、粮食种类、设备、出入库记录之间有明确关联，用MySQL管理天然合适。如果题目换成淘宝那种高并发商品详情，你可能需要讨论缓存和分库分表，但粮库管理系统的核心是保证数据一致性、历史可追溯和管理效率，MySQL完全够用，也方便导出Excel报表和写SQL统计。

2.2 环境准备：JDK、Maven、MySQL版本选择

我在帮人复现这套项目时，踩得最多的坑反而不是代码，而是环境版本不匹配。这里先给一个稳妥的组合：

这里特别提醒一点：如果MySQL是8.0，连接串里最好加上useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true。很多同学启动项目报Public Key Retrieval is not allowed，就是因为少了后面那个参数。这是MySQL 8.0的认证机制导致的，并不是代码问题。

2.3 项目骨架搭建与核心配置

如果是自己从零搭建，建议按这样的包结构组织：

code复制com.example.granary
├── common
│   ├── Result.java
│   ├── ResultCode.java
│   └── GlobalExceptionHandler.java
├── config
│   ├── MybatisPlusConfig.java
│   └── WebMvcConfig.java
├── controller
│   ├── GrainBarnController.java
│   ├── StockInController.java
│   ├── StockOutController.java
│   ├── DeviceController.java
│   └── MaintenanceController.java
├── entity
│   ├── GrainBarn.java
│   ├── StockInfo.java
│   ├── StockInRecord.java
│   ├── StockOutRecord.java
│   ├── DeviceInfo.java
│   └── DeviceMaintenance.java
├── mapper
│   └── 对应实体Mapper接口
├── service
│   ├── StockService.java
│   ├── DeviceService.java
│   └── ...
└── GranaryApplication.java

这种结构在答辩的时候也好看，老师一眼就能看出你理解分层。持久层如果源码用的是MyBatis-Plus，可以省掉大量单表CRUD的XML；如果用的是Spring Data JPA，也差不多。不过从我复现的这套源码看，MyBatis-Plus更常见，因为它生成分页、条件查询都很方便。

application.yml里最核心的一段配置是这样：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/granary_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

从这段配置里能看出三个提前规划好的点：字符集用utf8，避免中文乱码；mybatis-plus打印SQL，方便调试时排查问题；逻辑删除配置了deleted字段，在删除仓房或设备的时候不是真删，而是打标记。这个设计在答辩时也可以作为亮点提一下，体现出你对数据安全性的考虑。

2.4 统一返回体和异常处理，提升代码规范感

很多毕设源码最大的问题是每一个Controller返回类型都不一样，有的返回ModelAndView，有的直接返回String，前端解析全靠硬编码。我建议不管是自己写还是改造这套粮库系统，都要有一个统一结果类，类似这样：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

再配合@RestControllerAdvice做全局异常捕获，接口层会干净很多。比如库存不足时抛一个自定义异常，前端拿到统一格式的错误信息，弹窗提示，逻辑很清晰。这个设计说起来很小，但代码质量提升非常明显。

3. 核心数据模型：粮仓、库存、设备三张主表的设计与关系

3.1 粮仓信息表：从仓号到温湿度监测

粮库管理首先得有仓房档案。仓房表是整套系统的地基，字段设计不能太随意。我从实际系统中抽出一版比较合理的表结构：

为什么仓房表里直接放温度和湿度？因为粮库管理系统经常要在首页做展示，如果每次都要关联设备表实时计算，查询会慢，逻辑也绕。直接在仓房表冗余当前温湿度字段，由设备数据更新或者手动录入，对毕设来说更实用。你可以在答辩时说清楚这是“以空间换时间”的冗余设计。

3.2 库存主表与出入库流水表，千万别做成一张表

这是整套系统设计里最关键的决策。我见过不少同学把入库和出库记录直接放到同一张表，用一个type字段区分是入还是出，然后统计当前库存时对全表做SUM计算。这种方法在数据量小的时候没问题，但一旦演示数据一多，统计查询会变慢，而且无法保存每个仓房的实时库存状态。

正确的做法是拆成三张表：

• stock_info：库存主表，一个仓房加一种粮食对应一条记录，保存当前数量。
• stock_in_record：入库流水表，每次入库追加一条。
• stock_out_record：出库流水表，每次出库追加一条。

库存主表的字段大致是：

入库流水表则要记录record_no（单号）、supplier（来源）、quantity、operation_user（经办人）、record_time、remark。这样的好处是历史单子可以随时翻，库存主表只用做实时汇总，查询效率高，逻辑也清楚。

3.3 设备档案与保养记录，用关联字段串起业务

设备管理模块的表结构相对简单，核心是设备表device_info和保养记录表device_maintenance。

设备表字段包括device_no、device_name、device_type、barn_id（关联仓房）、install_date、manufacturer、status，以及maintenance_cycle（保养周期天数）。保养记录表字段包括device_id、maintenance_date、next_date、handler、content、status。

这里有一个细节：下一次保养日期不是每次保养时随便填的，应该根据maintenance_date + maintenance_cycle自动计算。例如某台设备3月1日保养，周期60天，那下次保养日期就是4月30日。系统根据next_date和当前日期比较，就可以在首页生成待保养清单。这个逻辑很基础，但把“业务规则”揉进了系统，答辩时能讲的东西就从“增删改查”变成了“周期性业务计算”。

3.4 表单校验和字段约束容易被忽略

复现这套源码时我发现，很多报错其实不是Bug，是数据没按规则填。比如仓房容量填了负数，入库数量填了字母，设备保养日期格式不对。为了避免这种低级问题，实体类上建议加上JSR-303校验注解：

java复制@NotBlank(message = "仓房编号不能为空")
private String barnCode;

@NotNull(message = "仓房容量不能为空")
@DecimalMin(value = "0", message = "容量不能为负数")
private BigDecimal capacity;

Controller方法参数上加@Validated或@Valid，数据错了直接统一返回提示。别小看这些注解，它能让你的代码在演示的时候更抗造，老师随手输一个非法数据也不会导致页面报红。

4. 核心业务实现：从入库登记到设备保养提醒

4.1 入库登记的事务处理，防止库存对不上

入库登记是整套系统的命门。如果这一步做不好，后面库存台账全是错的。我见过一些毕设代码，入库时先查一次库存，然后再更新，两步之间没加事务，极端情况下会出现重复提交导致库存翻倍。

比较靠谱的写法是：

java复制@Transactional(rollbackFor = Exception.class)
public void stockIn(StockInRequest request) {
    // 1. 校验仓房是否存在且已启用
    GrainBarn barn = grainBarnMapper.selectById(request.getBarnId());
    if (barn == null || barn.getStatus() != 1) {
        throw new BusinessException("仓房不存在或已停用");
    }

    // 2. 保存入库流水
    StockInRecord record = new StockInRecord();
    record.setBarnId(request.getBarnId());
    record.setGrainType(request.getGrainType());
    record.setQuantity(request.getQuantity());
    record.setOperationUser(request.getOperationUser());
    record.setRecordTime(new Date());
    stockInRecordMapper.insert(record);

    // 3. 更新库存主表
    StockInfo stockInfo = stockInfoMapper.selectByBarnAndGrain(request.getBarnId(), request.getGrainType());
    if (stockInfo == null) {
        stockInfo = new StockInfo();
        stockInfo.setBarnId(request.getBarnId());
        stockInfo.setGrainType(request.getGrainType());
        stockInfo.setQuantity(request.getQuantity());
        stockInfo.setUnit("吨");
        stockInfoMapper.insert(stockInfo);
    } else {
        stockInfo.setQuantity(stockInfo.getQuantity().add(request.getQuantity()));
        stockInfoMapper.updateById(stockInfo);
    }
}

这里的核心是@Transactional，保证流水插入和库存更新要么都成功，要么都失败。如果不用事务，演示的时候拔个网线或者系统崩了，库存就乱了。这一步代码在答辩时非常加分，因为很多同学根本没考虑数据一致性问题。

4.2 库存汇总与列表查询，避免N+1问题

使用MyBatis-Plus时，最方便的做法是用分页插件PaginationInnerInterceptor，然后写一个连表查询。例如查询库存列表时，需要显示仓房编号、仓房名称、粮食品种、当前数量。如果一个个循环去查仓房表，就产生了经典的N+1问题。

改进方式是直接在Mapper里写一个连表查询：

xml复制<select id="selectStockPage" resultType="com.example.granary.vo.StockVO">
    SELECT
        si.id,
        si.barn_id AS barnId,
        gb.barn_code AS barnCode,
        gb.barn_name AS barnName,
        si.grain_type AS grainType,
        si.quantity,
        si.unit
    FROM stock_info si
    LEFT JOIN grain_barn gb ON gb.id = si.barn_id
    <where>
        <if test="barnCode != null and barnCode != ''">
            AND gb.barn_code LIKE CONCAT('%', #{barnCode}, '%')
        </if>
        <if test="grainType != null and grainType != ''">
            AND si.grain_type = #{grainType}
        </if>
    </where>
    ORDER BY si.update_time DESC
</select>

配合MyBatis-Plus的分页插件，前端传个current和size，后端直接返回分页结果。这里要注意left join的时候别查成笛卡尔积，条件稍微控制一下。对毕设来说，这套查询方式已经足够专业了。

4.3 设备保养提醒：定时任务还是登录时扫描？

设备保养提醒至少有三种实现方案。第一种是Spring自带的@Scheduled定时任务，每天凌晨扫描一次device_maintenance表，把下次保养日期等于或临近今天的数据插入提醒表；第二种是每次登录时扫描未完成保养的设备，生成“待办事项”；第三种是数据库事件触发器，但毕设没必要折腾。

我推荐第二种，原因很简单：演示效果好，不需要等定时器触发。只要登录进首页，就能看到一个“待保养设备”列表，非常直观。代码大致是这样：

java复制public List<DeviceMaintenanceVO> listPendingMaintenance() {
    Date warningDate = DateUtil.offsetDay(new Date(), 7);
    return deviceMaintenanceMapper.selectList(
        new LambdaQueryWrapper<DeviceMaintenance>()
            .le(DeviceMaintenance::getNextDate, warningDate)
            .eq(DeviceMaintenance::getStatus, 0)
    );
}

这里把“未来7天内需要保养”定义为待办，你可以在系统配置里放一个参数，别写死。这样演示的时候还能顺带展示“配置化管理”这个细节。

4.4 Excel导出与文件上传的简化做法

毕设里免不了要做报表导出。如果你的技术栈里已经引入了Hutool，可以直接用Hutool的ExcelWriter，三五行代码就能把库存列表导出成Excel：

java复制ExcelWriter writer = ExcelUtil.getWriter(true);
writer.write(voList, true);
response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");
response.setCharacterEncoding("utf-8");
ServletOutputStream out = response.getOutputStream();
writer.flush(out, true);
writer.close();
IoUtil.close(out);

使用Hutool的好处是不需要额外学EasyExcel的复杂API，对课设来说完全够用。如果要导入Excel批量登记设备，也可以用ExcelUtil.read配合实体类注解实现。总之，复用成熟工具类，比手写POI解析省事得多。

5. 调试与部署：这套源码从本地跑通的完整路径

5.1 用IDEA导入项目后，先排除三分钟能解决的环境问题

很多同学拿到源码第一反应是双击运行，结果一上来就报错。我建议按这个顺序排除问题：先确认Maven依赖有没有下载完，再看Lombok插件有没有装，最后检查application.yml里的数据库连接。

最容易出现的错误是java: Cannot resolve symbol 'log'。这通常是因为IDEA没有启用Annotation Processing，或者Lombok插件没装。解决办法很简单：设置里搜索Annotation Processors，勾选Enable annotation processing，然后重启项目。如果还没有效果，就手动导入lombok依赖并重新加载Maven。

另外一个常见问题是项目里如果用了springfox 3.0.0作为Swagger依赖，在Spring Boot 2.6及以上版本启动时会报路径匹配错误。原因从Spring Boot 2.6开始默认匹配策略改成了PathPatternParser，而Swagger用的还是AntPathMatcher。解决方法是加一行配置：

yaml复制spring:
  mvc:
    pathmatch:
      matching-strategy: ant_path_matcher

这个坑在热搜词里反复出现，说明遇到的人非常多。你在改这套粮库系统时如果看到Swagger相关报错，先想到它。

5.2 数据库脚本执行顺序与初始化数据

源码包里一般会带granary_db.sql，但不要直接双击导入。建议先用Navicat或命令行创建一个数据库，字符集选择utf8mb4，然后在当前库上执行SQL脚本。

执行的时候注意有没有外键约束。如果脚本里有外键，建表顺序错了会导致建表失败。不过据我看到的多数毕设源码，都不会用物理外键，而是用逻辑关联，这样的好处是删数据方便，执行脚本也不容易报错。

初始化数据也很重要。比如演示时需要一些仓房、设备、用户数据。如果脚本里没有，你要手动插入几条。建议提前造一批像样的数据，比如某仓房温度35度触发高温预警，某设备下次保养日期今天到期。这些数据能让你演示时直接展示效果，不用现场操作半天。

5.3 配置分离：本地测试和生产打包用不同参数

源码里的application.yml一般写的是本地配置。如果你想部署到服务器，或者换一台电脑运行，最简单的做法是准备多个配置文件：

• application-dev.yml：本地开发，日志打印SQL。
• application-prod.yml：部署服务器，日志关闭，数据库连接独立。

在application.yml里通过spring.profiles.active: dev切换。这样做的好处是换环境不用改代码，只改启动参数。对毕设来说，虽然不上生产，但能体现你对配置管理的理解。

5.4 打包jar部署的常见坑

需要把项目发给别人演示或者部署到服务器时，用mvn clean package打包。这里有几个坑必须提前排掉。

第一个坑：打出来jar包双击不能运行，提示no main manifest attribute。这是因为没有Spring Boot的打包插件。在pom.xml里加上：

xml复制<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

第二个坑：打包后运行提示数据库连不上。大概率是配置文件里用了本机IP或者localhost，服务器访问不到。改成正确的主机地址，并确保服务器防火墙放行3306端口。

第三个坑：端口被占用。可以换一个端口，比如server.port: 8081，或者用命令netstat -ano找到占用进程，结束它。

来看一个常见的报错排查表：

6. 定制与改造：怎样把毕业设计变成“自己的设计”

6.1 加一个字段、加一个页面的完整链路

很多同学觉得改造源码很难，其实毕设项目的定制通常是“加字段”。比如我想在设备表里加一个“设备责任人”字段。完整链路是这样的：

第一步，在数据库表device_info里加一列owner_name varchar(50)；第二步，在实体类DeviceInfo里加属性private String ownerName;；第三步，如果用的是MyBatis-Plus，单表查询不需要改Mapper；第四步，在新增和编辑设备的表单页面加一个输入框；第五步，列表页显示这个字段。整个过程不超过二十分钟。

如果是自己从零写代码，最难的反而是前后端数据绑定。所以拿到这套源码后，先花一个小时把核心页面的前后端传参流程读一遍，搞清楚哪些参数是查询条件，哪些是表单提交，后面改造会顺畅很多。

6.2 从“管理系统”升级为“智慧粮库”的切入点

如果想让你的毕设看起来更有技术含量，可以在原项目基础上加“模拟温湿度采集”和“可视化大屏”。思路很简单：写一个定时任务，每隔几秒更新仓房表的温度和湿度字段，前端用ECharts折线图展示某个仓房最近24小时的变化曲线；当温度超过预警阈值时，在首页生成红色告警卡片。

这种改造不需要重写业务逻辑，只是在现有粮仓表上增加“实时数据”的维度。技术点也不难：后端可以提供一个/barn/temperature/trend接口，返回最近24小时的数据列表；前端引入ECharts，初始化一个折线图。但答辩效果会非常明显，因为能从“CRUD管理”跨到“物联网数据可视化”的层面。

6.3 论文与技术文档的素材组织

如果是毕设，源码之外最重要的就是论文和设计说明书。这套粮库系统的文档结构一般包括：课题背景、需求分析、系统设计、数据库设计、系统实现、系统测试。我在辅导时会让同学们重点整理三块内容。

第一块是数据库设计，把表结构说明、E-R图、字段注释都整理清楚。第二块是核心功能实现，重点写入库登记的业务流程和库存更新逻辑，配上核心代码片段。第三块是测试过程，至少要有功能测试用例表、异常测试结果截图。把这些整理好，论文的工作量看起来就非常饱满。

准备答辩PPT时，也可以按“业务背景—系统架构—数据库设计—核心功能演示—总结展望”的顺序来。演示不要超过八分钟，重点演示入库登记、库存查询、设备保养提醒这三个闭环功能，效果足够好。

6.4 调试定制服务里最常见的交流问题

最后聊一下定制服务中最常见的坑。很多人拿着源码来问问题，只发一句“报错了”，连日志都不带。我一般会让他们把完整的报错堆栈发过来，最好还有数据库脚本和代码位置。这样定位问题的速度会快很多。

如果是让别人帮你改需求，一定要把需求具体化。比如“我想在库存页面加一个按粮食品种筛选的功能”，比“你帮我把库存优化一下”好落地得多。需求描述越具体，沟通成本越低，改出来的东西也越符合预期。

这套粮库管理系统本身不算复杂，但它胜在业务真实、结构清晰、扩展空间大。我个人觉得，拿到源码之后不要急着问“能不能加这个功能”，先把它跑通，再沿着入库登记这条主线去读代码，读通了之后你会发现，后面所有的定制都是围绕“数据流转”在做文章。改完第一个功能，你心里就有底了。