1. 这个毕设题目到底在考察什么：选题价值与技术栈选型逻辑
仓库管理系统（WMS）几乎是计算机专业毕业设计里“常青树”级别的题目，而这套“基于SpringBoot+Vue的智能仓储信息管理平台”之所以值得做，不是因为它名字里带了“智能”两个字，而是因为它覆盖了企业级Web开发中最核心、最常被问到的一整条链路：权限控制、库存建模、业务流程设计、前后端分离、事务处理、部署上线。换句话说，它不是一道只考“能不能写出来”的题，而是一道考“你有没有完整做过一个项目”的题。
先说结论：这个题目适合三类人。第一类是后端方向偏弱、想借一个完整项目补齐SpringBoot基本功的人；第二类是前端主要靠Vue框架写页面、但缺少业务场景练手的人；第三类是准备求职、需要拿一个“有点东西”的项目讲清楚自己在开发中做了什么的人。只要踏踏实实把入库、出库、库存盘点、预警、权限这几条链路做通，无论是答辩还是简历，都很能拿得出手。
技术栈选型方面，Java + SpringBoot + Vue这套组合的优势很明显。SpringBoot解决了传统SSH/SSM项目里大量繁琐的XML配置问题，内嵌Tomcat，jar包一键运行，非常适合课程设计体量的项目。Vue作为前端渐进式框架，配合Element UI或者Element Plus能快速搭建后台管理界面，列表、表单、弹窗这些后台系统的“常规元素”都是现成的组件，写起来效率很高。MySQL是仓储数据的天然存储方案，Redis如果做进去，可以用来处理登录会话和缓存热点数据，加在这一层能让系统的“智能”二字落地得更实际一些。
这里我要多说一句：论文和开题报告里写“智能”，别把它讲成人工智能。仓储场景里的“智能仓储信息管理平台”，核心是把规则引擎化——比如库存低于预警值自动标记、先进先出（FIFO）自动推荐出库批次、库存周转率自动计算。把这几件事做扎实，比生硬地蹭一个什么算法进去实在得多，答辩老师也更容易听懂、更容易认可。
整个项目做下来，我建议按“数据库先行 → 后端接口 → 前端页面 → 联调 → 部署”的顺序推进，不要想着先写前端页面再倒推表结构。仓储系统最大的坑，往往不在代码里，而在数据模型上。先看表怎么设计，就知道系统能承载多大复杂度。
2. 系统架构与工程结构：模块划分、分层逻辑和前后端分离的实际落地方式
2.1 后端项目的包结构与分层思想
后端工程我建议直接用Maven构建，SpringBoot版本选2.7.x，JDK选1.8。这里特意强调版本，是因为很多同学一开始就上JDK 17甚至21搭配SpringBoot 3.x，结果遇到javax包名变成jakarta的问题，网上查资料费半天劲，还没有必要。毕设系统用JDK 8 + SpringBoot 2.7是最稳的组合，踩坑成本最低。
包结构按照标准的三层架构来分，但不要分得过度抽象：
com.xxx.wms ├── controller # 接收请求、参数校验、返回结果 ├── service # 业务逻辑处理（事务边界在这里） ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体映射 ├── dto # 接收前端参数的对象 ├── vo # 返回前端数据的对象 ├── config # 配置类（跨域、拦截器、MyBatis-Plus分页插件、异常处理） ├── common # 统一返回结果封装、业务异常类 └── utils # JWT工具、日期工具等Controller层只做三件事：接收参数、调用Service、返回统一结果。业务判断一律下沉到Service层，尤其涉及多表更新的场景，必须在Service层加事务注解。要用好@Transactional，默认情况下它只能回滚RuntimeException及其子类，所以业务异常一定要自定义成运行时异常的子类，否则方法结束后报错不生效，这一步卡过无数人的答辩演示。
统一返回结果封装是必做项。不要直接在Controller里return Map，定义一个Result 类，包含code、message、data三个字段。前端拿到响应后规范统一，几分钟时间，后面省很多事。
2.2 前端项目的工程化实践
前端项目用Vue CLI或者Vite初始化都可以，仓库管理系统这类中后台项目我建议用Vue 2 + Element UI，或者Vue 3 + Element Plus，两者没本质差别，看你个人熟悉哪个。如果时间紧迫，Vue 3 + Vite + Element Plus + Pinia是目前比较新的组合，上手成本并没有比Vue 2高多少。
前端目录结构按功能模块组织，而不是按组件类型堆在一起：
src ├── api # 每个模块一个API文件，统一封装axios请求 ├── router # 路由配置，含动态路由和路由守卫 ├── store # 全局状态管理（用户信息、菜单权限） ├── views # 页面组件，按模块分目录（user/ goods/ stock/...） ├── components # 公共组件（上传组件、选择器、标签等） └── utils # request实例封装、工具函数强调一下api目录的重要性。我见过很多同学把axios请求直接写在视图组件的methods里，一个接口调用七八个地方。正确做法是把所有接口在api目录集中管理，导出函数，组件里只调用函数。这样后端改地址、统一加请求头、处理异常拦截，都只动一处。
request实例封装要统一处理三件事：请求头携带Token、响应拦截器里的业务错误处理（code不为200时的提示）、网络错误处理（401跳转登录页）。这块代码是所有后台系统的生命线，做好了，全局的鉴权逻辑就不会乱。
2.3 前后端交互规范与API约定
前后端分离项目最大的磨合成本，是接口定义不统一。我的习惯是提前定一套“接口规约”：URL路径用名词复数，不用动词；RESTful风格，GET用于查询、POST用于新增和复杂查询、PUT用于更新、DELETE用于删除；分页参数统一是pageNum和pageSize；返回值统一是Result 。
以一个货品列表接口为例，后端Controller大概是这么写的：
@GetMapping("/goods") public Result<IPage<GoodsVO>> list( @RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) String keyword) { return Result.success(goodsService.queryPage(pageNum, pageSize, keyword)); }前端对应的api定义是：
export function getGoodsList(params) { return request({ url: '/goods', method: 'get', params }) }这样一个对不齐的坑是：后端的字段命名是驼峰（goodsName），前端如果直接用数据库字段改名会串味；接口层必须定义统一的VO，不要直接把Entity类返回给前端。“直接返回Entity”是毕设项目里最常见的偷懒做法，一旦表结构加了字段，或者某个字段不想暴露给前端，你就要全局找引用点，非常痛苦。我在这上面吃过亏，后面单独设VO类，一劳永逸。
3. 仓储数据模型设计的核心细节：库存表、流水表和事务一致性的底层逻辑
3.1 核心表设计：从基础数据到业务主表
仓储管理系统的数据库设计，我建议围绕下面几张核心表来建模：
- 用户表（sys_user）：用户名、密码、真实姓名、角色ID、状态。
- 角色表（sys_role）和用户角色关联表（sys_user_role）：做RBAC权限模型，一个用户可以有多个角色。
- 菜单/权限表（sys_menu）：菜单名称、路由地址、权限标识。
- 货品表（goods）：货品编码、名称、规格型号、单位、分类、预警库存值、状态。
- 仓库表（warehouse）：仓库名称、编码、地址、联系人。
- 库位表（location）：库位编码、所属仓库ID、状态描述。
- 供应商表（supplier）：供应商名称、联系人、电话、地址。
- 入库单表（stock_in_order）和入库明细表（stock_in_order_item）：主表记录入库单号、供应商、入库时间、操作人；子表记录货品、数量、库位、生产日期。
- 出库单表（stock_out_order）和出库明细表（stock_out_order_item）：主表记录出库单号、客户/领用人、出库时间；子表记录货品、数量、原始库位。
- 库存表（stock）：核心位置，一个库存记录代表“某个货品在某个库位有N件”，即库存按库位维度存储。
- 实时库存快照或记录表（inventory_record）：用于盘点、批次追溯和报表展示。
这里最重要的设计决策是：库存表不要只写一个货品总量字段，要按“仓库 + 库位 + 货品”这个粒度去拆。为什么呢？因为仓库系统的核心操作不是“加减一个数”，而是“从哪来、放到哪、从哪出”。你把库存细化到库位，后面出库才能做到先进先出，盘点才能定位到具体位置，否则数据看起来很完整，实际业务一跑就乱。
3.2 入库与出库的事务边界：先操作主表，再操作明细，最后更新库存
仓储系统写代码最容易出问题的点在于业务链路长、跨表多，任何一个环节失败都会导致库存和单据不一致。以入库为例，完整的业务逻辑是：
- 生成入库单号，主表插入入库单记录；
- 逐条在入库明细表插入货品、数量、库位信息；
- 对库存表做“有则加，无则插”的更新；
- 记录操作日志。
这四个步骤必须处于同一个事务中。如果采用默认的自动提交，插入主表成功、更新库存失败，账就对不上。我的做法是Service层方法上加@Transactional(rollbackFor = Exception.class)，并且手动在方法内捕获异常做业务判断，该回滚就回滚。
出库逻辑比入库稍微复杂一点，因为要面对“库存不足”的情况。出库前先查这条货品的总库存，再查库位明细，按最早入库时间或生产日期排序之后逐库扣减。这一步必须放在事务里，并且要用“悲观锁”或“乐观锁”防止并发出库时重复扣减同一批库存。
实际项目中我先用了乐观锁（库存表加version字段，update时校验version），后来发现并发不高的话其实用数据库的原子更新更简单。关键代码是这一行：
int rows = stockMapper.reduceStock(stockId, quantity); if (rows == 0) { throw new BusinessException("库存不足，扣减失败"); }用“受影响行数是否等于0”判断是否扣减成功，比查出来再判断更可靠。这是一种典型的并发控制方法，教材里叫原子条件更新，代码里其实就是一条带WHERE条件的UPDATE。
3.3 流水表的价值：为什么库存操作必须“留痕”
很多课程设计只做“当前库存”这一张表，出库了就把数字减掉，入库了就加上。这样做能跑通，但答辩时很容易被问倒：“你如何追溯一个月前某天某批货发生了什么操作？”“如果发现盘点数量不对，怎么排查是入库多了还是出库少了？”
这就是流水表存在的意义。我会在库存表之外，建立库存变动流水表（stock_flow），字段包括：流水号、货品ID、库位ID、变动类型（入库/出库/盘盈/盘亏/调整）、变动前数量、变动数量、变动后数量、关联单据号、操作人、操作时间。每次入库和出库，在更新库存的同时插入一条流水。
流水表最重要的作用是把“结果”变成“过程”。前端可以做一个库存全景页面：选中某个货品，展示它的当前库存、近30天的出入库趋势、每一笔变动的时间和单号。这不仅是功能完整性问题，还是答辩时的加分项。老师一眼就能看出你真的理解了业务，而不只是背了几张表结构。
另外提醒一句：库存变动流水表和库存表的更新必须放在同一个事务里，并且由代码统一控制，千万不要预留余额或增量操作在数据库触发器里做，否则后期排查问题时，代码层面的逻辑和数据库层面的逻辑容易“分家”，非常难维护。
3.4 预警逻辑：库存低值预警和效期预警的算法实现
“智能”二字体现在业务规则上就是预警。最常见的预警有两种：
一种是库存低值预警：货品表里维护一个预警库存值（warningStock），查询时判断当前总库存是否低于该值，低于则标记为预警状态。可以在查询列表时用一条SQL完成，也可以在货品列表接口里做异步扫描推送通知，课程设计阶段我建议做成“查询时实时判断”，简单直观。
public List<GoodsVO> listWarningGoods() { return goodsMapper.selectWarningGoods(); }SQL层面就是比较库存合计和预警阈值：
SELECT g.id, g.goods_name, g.warning_stock, IFNULL(SUM(s.quantity), 0) AS current_stock FROM goods g LEFT JOIN stock s ON g.id = s.goods_id GROUP BY g.id, g.goods_name, g.warning_stock HAVING current_stock < g.warning_stock另一种是效期预警：食品、医药、化工这类商品有生产日期和保质期。出库时推荐最早生产日期的批次优先出库，临期商品在列表页标红提醒。效期预警的SQL就是计算DATEDIFF(生产日期 + 保质期天数, NOW())，低于临界天数就置为预警。这个逻辑背后是FIFO（先进先出）原则，仓储业务里很常见。答辩时能把这个规则讲清楚，比堆很多页面有价值得多。
4. 前后台核心功能模块的完整实现链路：登录权限、货品管理、入库出库和看板统计
4.1 登录认证与RBAC权限控制
登录模块的设计逻辑是：用户输入账号密码 → 后端校验（密码需要加密存储，Spring Security的BCryptPasswordEncoder是常见选择）→ 签发JWT Token返回给前端 → 前端把Token存储到localStorage并随请求头发送 → 后端通过拦截器或过滤器校验Token的有效性。
我用的是JWT + 自定义拦截器方案，不引入Spring Security，因为课程设计体量下Spring Security的过滤器链复杂度没必要，自己写一下拦截器反而更能讲清楚原理。核心拦截器逻辑大概是：
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; // 放行预检请求 } String token = request.getHeader("Authorization"); // 解析token，失败则返回401 return true; } }RBAC权限控制方面，后端需要建好菜单表和角色菜单关联表，前端路由根据登录用户返回的菜单列表动态生成。Vue Router里有动态路由的概念，也就是addRoute方法。登录成功后先调“获取用户信息”接口，拿到该用户有权限的菜单和按钮权限列表，再循环addRoute动态挂载。这样一来，“普通用户看不到管理菜单”“仓库管理员不能删除货品”这类需求就顺理成章实现了。
这个模块能讲的东西很多，答辩时老师必问。准备几个关键词：JWT无状态认证、密码不可逆加密、路由守卫拦截未登录用户、按钮级权限通过自定义指令v-permission实现。把这些都做出来，权限模块基本就无懈可击了。
4.2 货品与库存管理：列表、搜索、上下架、库存查看
货品管理的核心操作是CRUD，但它有两个比较典型的嵌入式场景值得展开：
一个是条件搜索。列表页通常有多个搜索条件：货品编码、名称模糊查询、分类下拉选择、预警状态开关。后端的查询条件不要用“拼接SQL字符串”的原始方式，而是用MyBatis-Plus的LambdaQueryWrapper，或者写XML动态SQL。LambdaQueryWrapper代码可读性高，也容易写，适合毕业设计。另外分页插件要记得配置，PaginationInnerInterceptor是MyBatis-Plus内置的分页插件，配好之后Page对象就能直接返回total和records，前端表格就能直接渲染了。
另一个是删除策略。货品只要有过入库记录，就一定不能物理删除，否则流水表和库存表的外键关联会断。正确的策略是逻辑删除：表里加deleted字段，查询时默认过滤deleted=0。MyBatis-Plus直接支持逻辑删除注解，配好之后所有查询自动带上deleted条件，非常省心。这一点很重要，论文里可以写“采用软删除机制，保证历史数据链路完整性”，非常加分。
4.3 入库与出库的流程化设计：单据页面、货品选择、批次推荐
入库单页面建议做成“主表 + 明细表”的弹窗式表单：点击新增入库 → 选择供应商、填写入库日期 → 在明细区域动态添加货品行（每行选货品、填数量、选库位、填生产日期）→ 提交。
前端实现时，明细行可以用“动态表格”来写：
<el-table :data="itemList"> <el-table-column label="货品" min-width="200"> <template #default="scope"> <el-select v-model="scope.row.goodsId" filterable placeholder="请选择货品"> <el-option v-for="g in goodsOptions" :key="g.id" :label="g.goodsName" :value="g.id" /> </el-select> </template> </el-table-column> <!-- 数量、库位、生产日期列类似 --> <el-table-column label="操作"> <template #default="scope"> <el-button type="danger" link @click="removeRow(scope.$index)">删除</el-button> </template> </el-table-column> </el-table>后端接收的时候用List ，一次接口把主表信息和明细列表一起接收。别拆成“先插入主表、再逐条调明细接口”，那样事务边界在两次HTTP请求之间是断开的，一条失败全乱。
出库时最关键的是“推荐出哪个批次的货”。如果库存按库位和批次粒度记录，就按生产日期从小到大排序，从最早的那批开始扣减。这个推荐逻辑放在前端还是后端？正确答案是后端。出库明细提交时，后端根据数量自动计算“从哪些批次扣、各扣多少”，前端只负责展示计算结果。这样做可以防止前后端逻辑不一致，也能在事务里完成校验。这个设计一讲出来，答辩老师基本就满意了。
4.4 看板统计：折线图、饼图和仪表盘的数据来源
看板页面是毕设展示的“门面”，通常包含：今日入库数、今日出库数、库存总量、预警库存个数、近7天出入库趋势图、库存分类占比图。这些数据来自三个维度：汇总统计（count/sum）、时间序列（分组统计）、分类分布（group by）。
后端写统计接口时，一般在Mapper里写自定义SQL。MySQL的DATE_FORMAT函数可以用来按天分组：
SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS order_count, SUM(total_quantity) AS total_qty FROM stock_out_order WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY day前端用ECharts渲染折线图和饼图只需要组装好xAxis的日期数组和series的数据数组，把接口数据映射一遍就行。这里一个小经验是柱状图和折线图，建议用同一份数据结构来渲染，既减少接口数量，又避免多个图表请求互相等待。我一般把“今日汇总 + 7天趋势 + 分类占比”合并成一个/dashboard/center接口，前端页面只发一次请求，加载体验好很多。
4.5 前端表单校验与用户体验细节
前端一定不能把用户输入的校验逻辑完全托付给后端，要做两层校验：一是Element UI表单的rules规则，二是提交前的二次校验拦截。必填项、数值范围、库存是否充足、出库数量不能大于当前库存这类校验，放在前端能给用户即时反馈，减少无效请求。
我踩过的一个实际教训是：出库数量填了小数也能提交成功。原因是后端Entity里quantity字段类型写成了Integer，数据库字段是int，前端输入小数时校验没拦住，后端也不会判断是否是整数。后来在DTO里用BigDecimal接收，前端rules加validator判断必须是正整数才放行，才算彻底解决。这种边界问题的处理过程，写进论文的问题分析章节非常有说服力。
5. 前后端联调阶段的坑与排查思路：跨域、日期格式、精度丢失和分页问题
5.1 跨域问题：预检请求和响应头的配置
前后端分离项目启动后，第一个大概率会遇到的问题是跨域（CORS）。前端跑在localhost:8080，后端跑在localhost:9090，前端fetch请求会报跨域错误。解决方式有两种，一种是前端通过Vite的proxy做代理转发，另一种是后端配置跨域过滤器。
开发阶段我推荐后端直接配置CorsFilter，集中管理允许的地址、方法和请求头：
@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }注意config.setAllowCredentials(true)和addAllowedOriginPattern("")组合使用，不要用addAllowedOrigin("")，否则带Cookie的请求会被拒绝。另外，如果后端加了JWT拦截器，一定要在拦截器里放行OPTIONS请求，否则预检请求先被拦截器拦截，跨域配置根本走不到。这两个坑是联调新手常踩的连环雷，提前配置好就能避开。
5.2 日期时间字段的序列化与反序列化
Java LocalDateTime和前端JS Date之间的格式问题，是另一个经典雷区。默认Jackson序列化LocalDateTime时，输出的是类似“2024-06-01T12:00:00”的ISO格式，前端如果想展示成“2024-06-01 12:00:00”，要么前端自己格式化，要么后端配置全局统一格式。
推荐的方案是在application.yml里做全局配置：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8同时注意前端往后端传日期时，别传“yyyy/MM/dd”这种和配置不一致的格式，尽量用组件库的value-format把日期先转成统一格式再提交。我曾经因为日期格式不一致，导致入库单的日期字段插入后全是0000-00-00，排查了半天才发现是时间格式不统一。
5.3 Long类型精度丢失：为什么列表数据的ID会变成一样的
数据库ID如果用雪花算法生成，是Long类型。Java后端返回给前端时，JSON序列化为Number，但JS的Number类型最大安全整数是2的53次方减一，雪花ID往往更大，于是前端拿到的ID精度丢失，多条记录的ID可能被截断成同一个值，导致编辑、删除操作全部错乱。
解决方式有三种：第一种 简单粗暴，把实体ID序列化成String类型，在ID字段上加@JsonSerialize(using = ToStringSerializer.class)；第二种是在全局配置里统一开启“Long转String”的序列化策略；第三种是改用数据库自增ID，绕开这个问题。
我建议课程设计阶段直接采用数据库自增ID。除非你明确想在论文里讲“分布式ID生成策略”，否则自增ID在答辩时没有压力，也能避免这个最头疼的前后端类型不匹配问题。如果非要用雪花ID，那么必须在DTO/VO层把ID转换成String传给前端，前端保存到localStorage和再次传参时都按字符串处理。
5.4 分页查询中的常见错误与排查路径
分页查询报错主要集中在这几个场景：
- 前端传pageNum从0开始，后端PageHelper从1开始，导致第一页数据总是少一条或错位。解决方案：统一约定pageNum从1开始，前端分页组件的current-index从1开始。
- MyBatis-Plus分页插件没配置，执行Page查询时返回total始终为0，或者根本不分页。配置一下PaginationInnerInterceptor即可。
- 多表关联查询时分页SQL的count语句出错。如果用了自定义多表JOIN，建议把count查询单独写清楚，或者直接改用子查询方式，避免count语句生成的SQL桶。
排查这些问题的方法我总结了一条：不要看前端报错就改前端，先在浏览器开发者工具里看接口返回的数据结构是total和items，还是records和list，两头对齐后再动手。联调阶段70%的问题都能靠“打开Network面板看响应体”解决，比盲目改代码效率高很多。
6. 部署上线与答辩展示的实操要点：从本地到服务器、从演示到提问应答
6.1 后端打包与部署的注意事项
后端部署用的是SpringBoot的fat jar。pom.xml里配上spring-boot-maven-plugin，执行mvn clean package就能打出可执行jar。部署到Linux服务器上，用java -jar app.jar启动即可。
这里有三件事容易忽略：
第一，数据库连接参数不要写死在application.yml里，用环境变量注入。比如spring.datasource.password=${DB_PASSWORD}，部署时通过环境变量或启动参数指定。这样代码可以放进Git仓库而不泄露密码。
第二，上传文件的目录（如果有货品图片上传功能）要单独挂载出来，不要放在jar包内部的相对路径下。jar包换版本时，相对路径下的文件会被清空。我曾经部署第三次重启后发现上传的图片全丢了，教训深刻。
第三，如果服务器配置不高，启动时加上内存参数，比如java -Xms256m -Xmx512m -jar app.jar，避免内存溢出。
6.2 前端打包与部署方式
前端npm run build之后会生成dist目录，有两种部署方式。
一种是直接把dist目录里的静态文件复制到Nginx的html目录下，同时Nginx配置反向代理，把/api前缀的请求转发到后端的9090端口。这是最常用的前后端分离部署方式。
Nginx关键配置示例：
server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # 解决Vue刷新404问题 } location /api/ { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }注意location /里的try_files配置，它解决的是“前端路由在刷新页面时404”的问题。这个坑几乎是必踩的，不配这一行，刷新一下页面就白屏。
另一种方式是直接把dist目录放进SpringBoot的static目录下，让后端同时托管静态资源。这种方式适合毕设答辩场景，打包成一个jar就能跑，不用单独部署Nginx。但要注意如果后端配置了全局拦截器，要放行静态资源路径。
6.3 答辩演示时容易被追问的技术细节
演示阶段功能跑通只是基础，答辩问答才是拉开差距的地方。我建议你必须提前想清楚这几个问题的答案，确保随口就能说：
- “为什么用JWT而不用Session？”——答：服务端无状态，扩展性好，前后端分离场景下天然适合。补充说JWT的签名校验放在拦截器层，不用依赖Redis存储会话。
- “库存扣减并发时怎么保证不超卖？”——答：用数据库原子更新的受影响行数判断，或者加乐观锁version字段。平时讲的悲观锁也可以说上来。
- “如果入库单和库存更新有一半成功了怎么办？”——答：全部操作都在同一个@Transactional事务里，任何一步抛异常整体回滚。可以举例子说明：插入主表成功，扣库存失败，事务回滚，主表也不会保留这条单子。
- “前端怎么实现菜单权限？”——答：登录后返回菜单树，Vue Router动态addRoute挂载，未授权的路由即使手动输入地址也无法访问，后端接口再通过拦截器校验角色权限做双重保障。
准备到这种程度，答辩态度和项目理解都不会有硬伤。
6.4 关于“智能仓储”如何在论文里自我升华
最后说一点论文角度的小建议。这个题目在论文里可以用一个清晰的“三层架构”逻辑线组织：数据层做库存与流水建模，业务层做入库出库和预警规则，展示层做可视化与权限体系。把“智能”落位在规则上、把“管理”落位在流程上、把“系统”落位在架构上。整篇文章主线就是这三句话，答辩讲起来顺，论文读起来也清楚。
我在实际做这个项目的过程中最大的一点体会是：仓储管理系统这种业务型项目，价值不在于功能多炫，而在于每一笔数据流都链路完整、事务一致、可追溯。你能把“一张入库单从创建到库存增加再到流水留痕”的全过程讲明白，比多写一个没什么用的大屏报表要重要得多。如果时间充裕，建议优先把自定义权限指令、库存导入导出（EasyExcel）、出库批次推荐这几处做精，它们都是能说出实际业务含义的亮点，而不是纯堆页面。
这个项目做完之后，后面的扩展方向也很明确：引入Redis做高频数据的缓存和分布式锁，引入MQ做单据异步推送，引入Docker做环境一键部署。无论你继续深造还是去面试，这套架构都不是一个“毕设玩具”，而是一个真正能接得住后续需求的基础底座。
