Spring Boot+Vue仓库管理系统毕设实战：从数据库设计到部署答辩全流程解析

胖厨胡学斌·2026-09-16·阅读 21 GEO检测（免费）

Spring BootVue仓库管理系统

|难度：普通|阅读约 44 分钟

最近总有人私信问我：“学长，仓库管理系统这个题目每年都有人做，今年选是不是太老套了？”我每次的回复都一样：选题不看新旧，看它能不能让你顺利毕业，同时让答辩老师挑不出毛病。仓库管理系统恰恰是所有Java毕设题目里最像“毕业设计”的题目——它涵盖用户权限、数据建模、核心业务流、前端交互、部署上线，恰好卡在“有难度但不至于做不出来”的位置上。这篇就把我从零到一实现Spring Boot + Vue仓库管理系统的完整过程写出来，从数据库设计到部署排坑，从论文结构到答辩提问，全部摊开讲。

1. 仓库管理系统为何是Java毕设的“常青树”题目

1.1 毕设选题的潜规则：不选最炫，选最稳

计算机类的毕业设计，最大的风险不是做不出来，而是做出来之后你讲不清楚，或者评审老师觉得“工作量不足”。仓库管理系统在这一点上有天然优势：它不是一个纯展示型的CRUD小程序，而是带明确业务逻辑的企业级信息管理系统——货物要进、要出、要查、要统计，涉及库存变化、数据一致性和多角色权限。

从工作量看，一个完整的仓库管理项目至少包含以下模块：登录认证、用户权限、供应商管理、商品管理、入库管理、出库管理、库存查询、库存流水、统计报表、个人中心。十个模块摊下来，从需求分析到编码，再从测试到写论文，整个周期一个半月左右是比较真实的节奏。对于本科毕设来说，这个工作量既不会让导师觉得注水，也不会因为太复杂而让你在最后一个月崩溃。

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

1.2 为什么选了Spring Boot + Vue这套组合

技术选型的逻辑其实很现实：第一，这套技术栈是目前国内中小型公司的绝对主力，企业真实项目里大量在用，你写在简历上不会心虚；第二，社区生态成熟到令人发指，遇到问题一搜就有答案，尤其是对毕设这种需要自学完成的项目，这一点能救命；第三，从代码量角度，Spring Boot把Spring MVC的配置简化了一大截，Vue的前后端分离模式也让项目结构一目了然，两头都适合毕设答辩时清晰讲解。

另外我个人的偏好是：后端Spring Boot选2.7.x（后面细说版本问题），ORM层用MyBatis-Plus而不是JPA。原因很简单，MyBatis-Plus的代码提示直白，selectById、selectPage这些方法名一看就懂，配合SQL日志调试起来也直观，比JPA那套“你猜它背后执行了什么SQL”的黑盒体验对新手友好得多。前端用Vue 3 + Element Plus + Pinia + Axios，后面会逐个讲清楚它们各自解决什么问题。

2. 数据库设计：从库存台账到流水记录的完整建模思路

2.1 表结构整体规划：九张表如何支撑一套仓管系统

仓库管理系统的数据模型是整个项目的灵魂。许多同学一上来就建一张“库存表”，然后所有操作都往里怼，到后期做入库出库时发现逻辑乱成一锅粥。正确做法是把“基础资料”和“业务单据”分离开。我的项目里一共规划了九张核心表，分成三类：

系统权限类：sys_user（用户表）、sys_role（角色表）
基础资料类：wm_supplier（供应商表）、wm_product（商品表）、wm_warehouse（仓库表）
业务单据类：wm_stock_in（入库单）、wm_stock_out（出库单）、wm_stock（库存余额表）、wm_stock_record（库存流水表）

每张表的ID都统一用bigint类型，主键自增，所有表都保留create_time和update_time两个公共字段，方便统一排序和排查问题。字符集全部使用utf8mb4，排序规则utf8mb4_general_ci——如果你还纠结为什么不建议用utf8，一句话：utf8mb4能存emoji和生僻字，而且已经是MySQL 8的默认选择。

2.2 核心业务表设计：wxm_product和wm_stock的关键字段逻辑

商品表是基础资料里最核心的一张表。字段设计上除了常规的product_name、product_code、specification（规格）、unit（计量单位），我额外加了category（分类）和safety_stock（安全库存）。其中product_code是唯一索引，这个细节很关键——同一个商品在仓库里只允许存在一条主数据，否则后续库存统计会出现重复累加的问题。safety_stock这个字段很多人会忽略，但有了它，低库存预警功能就水到渠成，答辩的时候是一个很好的加分点。

库存余额表wm_stock的设计思路同样重要。它不是简单地记录“哪个商品有多少”，而是要以商品和仓库的组合维度保存当前可用库存量。所以表里同时包含warehouse_id和product_id两个外键字段，并加上唯一约束uk_warehouse_product(warehouse_id, product_id)。库存余额表只负责存“当前状态”，所有变化过程都交给流水表wm_stock_record。

2.3 库存流水表：让每一件货物都有迹可循的原理

wm_stock_record是我个人认为整个数据库设计中最值得在答辩时展开讲的表。它每一行都代表一次库存变化事件，字段包括：warehouse_id、product_id、change_type（变更类型，如1-入库/2-出库/3-盘点调整）、quantity（变更数量，正数加库存，负数减库存）、before_stock和after_stock（变更前后库存快照）、related_bill_no（关联单号）、create_by（操作人）、create_time（操作时间）。

为什么要存before和after两个快照？因为如果只存一个变化后的数量，一旦后续业务出错，你根本没法还原这个数字是怎么得来的。有了快照，随时能根据流水反推某一个时间点的库存状态，这就是审计追踪的雏形。我在答辩时就是这么讲的：“库存流水表的设计借鉴了会计学中的流水账思想，任何库存余额的变动都能在流水表中找到唯一对应的一笔记录。”这个表述在答辩时效果非常好，老师会认为你思考过数据一致性的问题，而不是单纯学着网上的教程建表。

3. 后端Spring Boot实现剖析：从统一返回结构到JWT鉴权落地

3.1 项目初始化与目录结构：提前规划胜过后面重构

创建后端项目时，版本选择非常关键。我推荐Spring Boot 2.7.18，而不是刚出的Spring Boot 3.x。原因很实际：3.x把javax包名改成了jakarta，很多教程和旧插件都不兼容，而且MyBatis-Plus在3.x下的某些starter还在完善中。对毕设来说，稳定的2.7.x搭配JDK 1.8或JDK 11，几乎不会遇到环境兼容的幺蛾子。

后端的包结构建议按职责划分，而不是按技术类型划分：

code复制com.warehouse
├── config       // 配置类，包括CorsConfig、MybatisPlusConfig、JwtInterceptorConfig
├── controller   // 控制器层
├── service      // 业务层接口
├── service.impl // 业务实现
├── mapper       // 数据访问层
├── entity       // 实体类
├── dto          // 数据传输对象
├── vo           // 视图对象
├── utils        // 工具类
└── common       // 公共类，R、ResultCode、异常处理等

这样的包结构在论文的“系统设计”章节里非常好画图描述。controller层只做参数接收和结果返回，service层写业务逻辑，mapper层不写SQL（复杂SQL写在XML里）。每一层的职责边界清晰，答辩时被问到“你这个项目如何体现分层思想”，直接按这个目录结构往上说就行。

3.2 统一返回结果R类：前后端对接的前提约定

前后端分离项目里最容易被忽略的就是接口返回格式不统一。前端拿到一个接口返回的是{code: 200, data: {...}}，另一个接口返回的却是直接在data里放一个数组，前端处理起来就得写一堆分支判断。我在项目里封装了一个通用的R<T>类：

java复制public class R<T> implements Serializable {
    private Integer code;
    private String message;
    private T data;

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

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

这个类看着简单，但它是前后端联调效率的关键。前端Axios拦截器里先判断res.data.code === 200，再统一处理业务数据，出错时用ElMessage直接弹出message字段。所有controller的返回值都统一成R<T>，后端不用为每个接口单独设计返回结构，前端也不用猜。这个约定一共花了十分钟写，省下来的联调时间少说两三天。

3.3 JWT认证的设计：拦截器+注解，权限控制不绕弯

仓库管理系统的用户权限一般有两种角色：管理员和普通操作员。管理员能操作所有功能，包括用户管理、入库审核；操作员只能进行日常的商品录入和出入库操作。这种简单的RBAC模型用路由守卫在前端控制就够了，但后端必须配合做接口级拦截，否则绕过前端页面用Postman直接调接口就能拿到数据，这在答辩演示时一旦被老师看出问题，会很尴尬。

我的实现方案是JWT + Spring MVC拦截器。用户登录成功后，后端生成一个token，里面存入用户ID和用户名，用io.jsonwebtoken的Jwts工具类进行签发和解析：

java复制// 生成token
String token = Jwts.builder()
    .setSubject(user.getUsername())
    .claim("userId", user.getId())
    .claim("role", user.getRole())
    .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24))
    .signWith(SignatureAlgorithm.HS256, secretKey)
    .compact();

这里有一点值得特别注意：secretKey不能写死在代码里，应该在application.yml中配置，通过@Value注解注入。别用系统生成的随机密钥——那样重启服务后所有已登录用户的token都会失效，实际测试时你需要反复重新登录，非常烦人。

然后写一个JwtInterceptor实现HandlerInterceptor接口，在preHandle方法里从请求头Authorization中取出token，解析成功就放行，失败则返回401状态码。为了区分哪些接口需要验证、哪些不需要（比如登录接口本身），我用自定义注解@PassToken标注放行接口，拦截器里判断如果方法上有这个注解就直接return true。这种“注解+拦截器”的方式比在配置里手写一串excludePathPatterns列表要优雅得多，论文的技术选型部分也多了一个可以展开讲的点。

3.4 核心业务逻辑：入库单如何在事务中保持库存一致

入库操作是整个系统最核心的事务。它涉及两步操作：第一步向wm_stock_in表插入入库单记录，第二步更新wm_stock库存余额表（有则增加，无则新增一条）。这两步必须在一个事务里完成，否则就会出现“单子录了，库存没加”的数据不一致问题。

我在StockInService里用@Transactional(rollbackFor = Exception.class)标注事务方法，rollbackFor指定任何异常都回滚。具体业务逻辑是这样写的：

java复制@Transactional(rollbackFor = Exception.class)
public void createStockIn(StockInDTO dto) {
    // 1. 插入入库单主表
    StockIn stockIn = new StockIn();
    BeanUtils.copyProperties(dto, stockIn);
    // 生成入库单号：RK+时间戳+随机数
    stockIn.setBillNo("RK" + System.currentTimeMillis() + RandomUtil.randomNumbers(4));
    stockIn.setStatus(1);
    stockInMapper.insert(stockIn);

    // 2. 查找是否已有库存记录
    Stock stock = stockMapper.selectByWarehouseIdAndProductId(dto.getWarehouseId(), dto.getProductId());
    if (stock == null) {
        stock = new Stock();
        stock.setWarehouseId(dto.getWarehouseId());
        stock.setProductId(dto.getProductId());
        stock.setQuantity(dto.getQuantity());
        stockMapper.insert(stock);
    } else {
        // 3. 更新现有库存
        int rows = stockMapper.increaseStock(dto.getWarehouseId(), dto.getProductId(), dto.getQuantity());
        if (rows == 0) {
            throw new RuntimeException("库存更新失败");
        }
    }

    // 4. 写入库存流水
    StockRecord record = new StockRecord();
    record.setWarehouseId(dto.getWarehouseId());
    record.setProductId(dto.getProductId());
    record.setChangeType(1);
    record.setQuantity(dto.getQuantity());
    record.setRelatedBillNo(stockIn.getBillNo());
    record.setCreateBy(SecurityUtils.getCurrentUserId());
    stockRecordMapper.insert(record);
}

这里有个很实用的技巧：increaseStock的SQL不是简单的quantity = quantity + #{increase}，而是要加一个quantity = quantity + #{increase}的update语句，然后用返回的rows受影响行数判断是否更新成功。如果库存记录已被并发删除，rows会是0，直接抛异常让事务回滚。这个“受影响行数校验”的技巧，在并发场景下比先查询再更新的方式安全得多，答辩讲出来也是加分项。

4. 前端Vue 3实现：从项目创建到库存看板的完整链路

4.1 快速了解Vue 3 + Element Plus + Pinia的门道

前端技术栈方面，Vue 3配合组合式API（Composition API）是目前的主流写法。使用<script setup>语法，代码比Vue 2的Options API更紧凑，逻辑复用的是自定义hooks，而不是mixins。对于仓库管理系统这种中型前端项目，Vue 3带来最大的收益不是性能，而是代码组织方式的清晰度。

Element Plus是Vue 3配套的UI组件库，仓库管理系统需要的表格、表单、弹窗、下拉选择、日期选择器、分页组件，它全部开箱即用。你不需要懂多深的CSS，就能做出一套界面层级分明、交互流畅的管理后台，这几乎成了Java毕设前端的事实标准。

状态管理我在项目中用了Pinia而不是Vuex。原因很单纯：Pinia的API设计更现代、类型提示更好，代码量也更少。在仓库管理系统里，Pinia主要用来存登录用户的token和用户信息。

javascript复制// stores/user.js
import { defineStore } from 'pinia'

export const useUserStore = defineStore('user', {
  state: () => ({
    token: localStorage.getItem('token') || '',
    userInfo: {}
  }),
  actions: {
    setToken(token) {
      this.token = token
      localStorage.setItem('token', token)
    },
    setUserInfo(info) {
      this.userInfo = info
    },
    logout() {
      this.token = ''
      this.userInfo = {}
      localStorage.removeItem('token')
    }
  }
})

4.2 Vue项目的工程化搭建：路由拆分、请求封装与权限控制流程

前端项目创建我直接用的Vite：

bash复制npm create vite@latest warehouse-ui -- --template vue
cd warehouse-ui
npm install
npm install vue-router@4 pinia element-plus axios

你会发现我没有装vuex，理由上面说过了。接下来重点说两个平时教程里很少细讲但实际项目必须做好的部分：路由和Axios封装。

路由部分，登录页之外所有页面都放在一个Layout布局组件下，这个Layout包含左侧菜单栏、顶部导航栏和右侧内容区，通过子路由切换页面。这样做的好处是整个后台框架的结构统一，新增页面时只需要在路由配置文件里加一个children节点。动态菜单虽然听着高级，但对于毕设项目来说，静态路由配置反而更稳定——动态路由在做浏览器刷新时容易丢失权限映射，处理起来要额外写一堆逻辑，性价比不高。

Axios封装这一块，核心逻辑都在拦截器里：

javascript复制// api/request.js
import axios from 'axios'
import { ElMessage } from 'element-plus'
import { useUserStore } from '@/stores/user'
import router from '@/router'

const request = axios.create({
  baseURL: '/api',
  timeout: 15000
})

request.interceptors.request.use(config => {
  const userStore = useUserStore()
  if (userStore.token) {
    config.headers['Authorization'] = userStore.token
  }
  return config
})

request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求失败')
      return Promise.reject(new Error(res.message || '请求失败'))
    }
    return res.data
  },
  error => {
    if (error.response && error.response.status === 401) {
      ElMessage.error('登录状态已过期，请重新登录')
      useUserStore().logout()
      router.push('/login')
    } else {
      ElMessage.error('网络异常，请稍后重试')
    }
    return Promise.reject(error)
  }
)

注意baseURL用的不是绝对地址，而是/api，这个前缀在开发环境下通过Vite的代理转发到后端，在生产环境中通过Nginx反向代理到后端服务。这是前后端分离项目部署的关键约定，但现实中很多同学在这里踩坑——开发时接口通了，打包后部署到服务器上就全是404或跨域报错，多半就是没处理这个路径转发。

4.3 核心页面实现细节：以入库单页面为例拆解全流程

以入库单新增页面为例子，实际操作流程是：选择供应商，选择仓库，然后在一个明细表格里选择商品、填写数量，再提交后端。

页面的核心逻辑分三步。第一步是在onMounted里去拉取供应商列表、仓库列表和商品列表，分别填充到三个下拉组件里；第二步是明细表格的交互，每一行有个“选择商品”的按钮，点开后弹出一个商品选择对话框，选中商品后把商品ID、名称、规格回填到当前行；第三步是提交逻辑，把表单主数据和明细数组组装成后端要求的JSON结构，调用//api/stockIn/create接口。

这里最值得分享的经验是Vue 3中表格行内数据的响应式处理。用的是reactive定义一个productList数组，每一行数据格式如下：

javascript复制const tableData = ref([])
const addRow = () => {
  tableData.value.push({
    productId: null,
    productName: '',
    spec: '',
    quantity: 1
  })
}

首次实现的时候，我的做法是商品选择对话框确认后，直接通过索引tableData.value[index].productId = selected.id修改那一行的数据，以为这样就能触发界面更新。结果发现一个奇怪的现象：表格里的商品名称更新了，但规格那一列死活不显示。排查了大半天，最后发现是因为Element Plus的表格列的prop名写错了——模板里写的是props="spec"，而我的数据字段名是specification。这种低级错误在前后端联调时很容易遇到，排查的思路很笨但很有效：先F12看接口返回的数据结构，再回前端页面看绑定的字段名，逐项对照。

4.4 库存看板与可视化报表：让毕设作品看起来更完整

仓库管理系统如果只有CRUD页面，答辩时视觉冲击力不够。我额外加了两个页面让项目整体观感上一个台阶：一个是首页的库存仪表盘，另一个是库存报表页面。

首页仪表盘用ECharts展示了三块内容：顶部四个统计卡片（商品总数、库存总数量、今日入库、今日出库），中间是最近7天入库出库趋势的折线图，下方是各仓库库存占比的饼图。ECharts的Vue封装用vue-echarts库，接入成本很低。

这里有个良心建议：ECharts图表的数据接口要单独设计，不要在首页接口里一次返回太多统计信息。我最初把今日入库数、今日出库数、商品总数都塞进一个/dashboard/stats接口，后来又发现做趋势图需要最近7天的数据，就另外加了一个/dashboard/trend接口。把统计口径拆开，每个接口只做一件事，前端也好维护，后端也好写SQL。

趋势图的SQL是一个典型的日期分组查询：

sql复制SELECT DATE(create_time) AS day,
       SUM(CASE WHEN change_type = 1 THEN quantity ELSE 0 END) AS in_count,
       SUM(CASE WHEN change_type = 2 THEN quantity ELSE 0 END) AS out_count
FROM wm_stock_record
WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY)
GROUP BY DATE(create_time)
ORDER BY day

这个SQL用到了SUM配合CASE WHEN把入库和出库分成两列，再用DATE_SUB筛选近7天，一张流水表同时支撑两个维度的统计。写这个SQL和数据组装逻辑大概花了半小时，但它很能体现你“数据库设计时考虑了报表需求”的意识。

5. 本地联调与服务器部署：从“在我电脑上是好的”到真正跑起来

5.1 开发环境的坑：Spring Boot版本、Node版本、依赖安装问题

先讲后端。Spring Boot项目创建时，如果IDE里选了最新版3.x，pom.xml里自动引入的依赖和旧教程的配置有很大出入。最典型的问题是spring-boot-starter-web的内部依赖变了，一些老版本的第三方包无法兼容。我的建议是直接锁定Spring Boot 2.7.18：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

千万注意，不要因为Maven仓库拉取慢就随意改镜像源里没有的版本号，会直接导致依赖冲突。前端这边，Vite需要Node.js版本在16以上，但也不是越高越好——Vite 4在Node 20以上的某些版本里会有告警，不影响使用但看起来心里膈应。如果npm install慢，可以设置淘宝镜像源：

bash复制npm config set registry https://registry.npmmirror.com

这个命令设置一次全局生效，以后新建项目装依赖速度会快很多。

5.2 前后端联调时的跨域问题：根因与三种解决方案对比

开发模式下，Vite默认跑在5173端口，Spring Boot跑在8080端口。前端直接请求http://localhost:8080/api/user/login时，浏览器会因为跨域限制拦截请求。我试过三种解决方案：

第一种，后端开启跨域配置，在Spring Boot里写一个CorsConfig类，配置允许跨域的路径、请求头和请求方法。这个方案适合开发阶段，但生产环境其实用不太上，因为你部署后通常走Nginx同域转发。

第二种，Vite的代理配置。在vite.config.js中配置：

javascript复制server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这种方式的好处是前端代码里不用写绝对地址，统一用/api开头，浏览器发出的请求还在同源下，不存在跨域问题。这是我推荐的方案。

第三种，前端代码里直接写完整的后端地址，配合后端CorsConfig。这个方案在本地能用，但打包部署后如果前后端不在同一域名下，会有正式环境跨域问题，不推荐。

5.3 前后端打包与Nginx部署：一次就搞定

本地开发完成后，部署到服务器一般是这样的流程。

后端先打包成jar包，在项目根目录执行：

bash复制mvn clean package -DskipTests

打包完成后在target目录下生成warehouse-0.0.1.jar，上传到服务器后用java -jar warehouse-0.0.1.jar启动。

前端打包：

bash复制npm run build

打包完成后生成dist目录，把dist目录上传到服务器，通过Nginx配置静态文件服务和反向代理：

nginx复制server {
    listen 80;
    server_name your_domain;

    # 前端静态文件
    location / {
        root /usr/share/nginx/html/warehouse-ui;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # 后端接口反向代理
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这段配置里最关键的是try_files $uri $uri/ /index.html;这一行。因为Vue路由默认是history模式，如果用户直接在浏览器输入某个子页面地址（比如/product/manage），服务器上并没有这个物理文件，没有这行配置的话会返回404。有了try_files，所有未匹配静态资源的路由都会回退到index.html，交给前端路由接管。

6. 论文撰写与答辩准备：代码跑通只算完成一半

6.1 论文框架：把“做了什么”变成“为什么这么做”

论文结构上，我见过太多同学按模板堆砌，第一章“背景意义”全是网络摘要拼凑，第三章“需求分析”抄软件工程教材的用例图，最后导师看完一头雾水。我自己的经验是：背景不要从计算机发展史讲起，直接从“仓管信息化”这个具体场景切入，说明为什么要设计一套系统；需求分析要从三种角色（管理员、操作员、普通用户）的视角列出功能表，画出角色-功能矩阵；数据库设计要把第二章的表结构设计思路穿插进去；系统实现章节按前后端分开写，每写一个功能模块的代码片段，都要紧跟一段业务逻辑说明，让老师知道你写这段代码解决的是什么业务问题。

我的论文章节安排：

第一章绪论：研究背景、国内外现状、研究内容与意义
第二章相关技术介绍：Spring Boot、Vue、MySQL、Element Plus的思想与选型理由
第三章系统分析：可行性分析、功能需求分析、非功能需求分析
第四章系统设计：总体架构设计、数据库设计（E-R图和表结构）
第五章系统实现：分模块描述关键功能与截图
第六章系统测试：功能测试用例表、测试结果分析

这个框架看起来常规，但胜在稳。老师在毕业设计答辩里看重的无非是三件事：论文和系统是否一致、工作量是否充足、是不是自己做的。按照这个框架写，三个要素都覆盖了。

6.2 答辩高频提问与回答思路：被问住也不慌

答辩时老师最爱问的问题，我听得最多的是这几个：

问题一：库存表和库存流水表为什么要分开设计？ 回答思路：库存表保存当前余额，流水表保存变更历史。如果没有流水表，一旦库存数据错误就无法追溯，分开后每次变更都有据可查，符合审计要求。

问题二：JWT和传统Session有什么区别，为什么选JWT？ 回答思路：Session存在服务端，分布式环境下需要session共享方案；JWT是无状态的，token里直接携带用户信息，后端不需要保存会话，适合前后端分离和水平扩展。

问题三：数据库性能优化做过哪些？ 回答思路：一是列表查询都用分页，避免一次性返回大量数据；二是热门查询字段加上索引，比如商品编码的唯一索引、库存表的联合唯一索引；三是库存统计走流水表按日期聚合，不在业务高峰期实时计算。

问题四：这个系统安全方面怎么考虑的？ 回答思路：后端统一做JWT拦截器校验，接口层面做了权限控制；前端路由也做了登录守卫；密码存储使用MD5加盐（如果再讲究一点，可以改用BCrypt加密）。

问题五：出库时遇到库存不足怎么处理？ 回答思路：在后端service里先查询库存，如果当前库存小于出库数量，直接抛出业务异常，事务回滚，前端收到错误提示后给出提示信息，不允许提交出库单。

7. 一段话再说说这个项目的实际体会

写到这里，整个仓库管理系统从选题到上线答辩的路径就完整了。最后分享一个我做这个项目时的切身体会：毕设这东西，拼的不是代码写得多花哨，而是逻辑能不能自洽、功能能不能闭环。仓库管理系统之所以值得推荐，就是因为它天然自带闭环——从入库到出库到统计报表，每个模块之间的数据流转是紧密咬合的，你每完成一条链路，系统就多一分真实感。如果你正在这个题目的边缘犹豫，不用再想了，按这篇思路去动手实现，稳扎稳打做完，答辩时你心里是踏实的。