Java+Spring Boot+Vue+微信小程序WMS仓库管理系统实战：扫码入库与库存事务设计

简介：这份资源是一套基于Java、Spring Boot与Vue.js构建的WMS仓库管理系统，并集成微信小程序端，面向计算机相关专业的毕业设计学生及需要仓库管理实战项目的开发者。系统覆盖入库、出库、库存管理、订单处理等核心业务，Web端与小程序端双端协同，用户可通过微信小程序随时查看库存、下单与追踪物流，适合作为毕设选题或全栈学习参考。压缩包为zip格式，整体约12.24MB，内含后端Java源码、Spring Boot配置文件、Vue组件、数据库SQL脚本、微信小程序配置及需求分析与设计文档等，覆盖软件开发全流程。目前已有217人学习下载。读者可从中获取完整的项目结构、前后端接口设计思路与数据库表结构，对照文档理解需求分析到编码测试的各个环节，并借鉴小程序与后端联调的实践方式，为自身毕设或类似系统开发提供可复用的参考方案。

1. 从一张 Excel 库存表到扫码入库：WMS 仓库管理系统到底在解决什么

很多中小仓库的日常是这样的：入库靠一张 Excel 表，出库靠微信群喊一声，月底盘点发现账实差异几十件，谁也说不清货去哪了。基于 Java + Spring Boot + Vue 的 WMS 仓库管理系统，加上一个微信小程序扫码端，解决的正是这个场景——把「收货、上架、拣货、复核、盘点」这几个动作从纸面搬到系统里，让每一次库存变动都有单据、有操作人、有时间戳。它适合谁？适合有 1～3 个仓库、SKU 在几百到几千量级、想自己掌控源码做二次开发的团队，也适合 Java 后端工程师拿它练手一个完整的前后端分离项目。核心链路其实就一句话：Spring Boot 提供 REST 接口和库存事务，Vue 做 PC 端管理后台，微信小程序做现场扫码作业，三者共用一套库存数据。

2. 技术选型与整体架构：为什么是 Spring Boot + Vue + 小程序三件套

2.1 后端为什么选 Spring Boot 而不是传统 SSM

WMS 的业务特点是「事务密集 + 单据状态流转多」。一次入库要同时写库存主表、库存流水、入库单状态，任何一步失败都得回滚。Spring Boot 的声明式事务@Transactional配合 MyBatis 或 MyBatis-Plus，能把这类多表操作收敛在一个 service 方法里，比手写 XML 配置的 SSM 省掉大量样板代码。另一个现实原因是生态：分页用 PageHelper、权限用 Spring Security 或 Sa-Token、定时任务用@Scheduled做库存预警，这些都是现成轮子。

选型时要注意版本搭配。热搜里常出现「springboot版本太高」的抱怨，根源多是 JDK 版本和依赖不匹配。我一般这样定基线：

提示：Spring Boot 3 把javax.*换成了jakarta.*，如果你抄的教程还是javax.servlet，启动就会报类找不到，这是新手最常见的翻车点。

2.2 前端 Vue 与小程序的分工边界

一个常见误区是「有了小程序就不需要 PC 后台」。实际上两者的使用场景完全不同：PC 端 Vue 后台负责商品档案维护、入库单审核、报表导出、权限配置这类重操作；微信小程序负责现场扫码——收货员拿手机扫商品条码确认数量，拣货员扫库位码核对。小程序不适合做复杂表格和批量操作，PC 端不适合拿着手机在货架间走动。

所以架构上，小程序和 Vue 后台调用的是同一套后端接口，只是权限角色不同。后端用 JWT 或 Token 区分登录来源，小程序端登录走wx.login换 openid，PC 端走账号密码。这样库存数据只有一份，不会出现「小程序改了 PC 端看不到」的脏数据。

2.3 数据库表设计的核心几张表

WMS 的表不用多，但几张核心表必须设计对，否则后期改起来很痛：

• wms_goods：商品档案，含 SKU 编码、条码、规格、单位
• wms_warehouse/wms_location：仓库与库位，库位编码是扫码的关键
• wms_stock：库存主表，字段是「商品 + 仓库 + 库位 + 数量」，唯一索引建在这三者上
• wms_stock_record：库存流水，每次增减都插一条，用于追溯
• wms_inbound_order/wms_outbound_order：入库单、出库单及明细

库存主表的唯一索引是重点。很多新手把库存直接存在商品表的一个quantity字段里，结果多库位场景直接崩掉。正确做法是库存按「商品 + 库位」维度存，汇总数量靠SUM查询或缓存。

3. 后端落地：库存事务、单据状态机与接口设计

3.1 用 Spring Boot 写一个不会超卖的入库接口

库存操作最怕并发。两个人同时拣同一批货，如果不加锁，就会出现超卖。下面是一个入库接口的核心写法，用乐观锁或行锁保证数量正确：

@Service public class StockService { @Autowired private WmsStockMapper stockMapper; @Autowired private WmsStockRecordMapper recordMapper; /** * 入库：增加指定库位的库存，并写一条流水 * @param goodsId 商品ID * @param locationId 库位ID * @param qty 入库数量，必须为正 */ @Transactional(rollbackFor = Exception.class) public void inbound(Long goodsId, Long locationId, Integer qty) { if (qty == null || qty <= 0) { throw new BizException("入库数量必须大于0"); } // 先查库存行，加行锁（SELECT ... FOR UPDATE） WmsStock stock = stockMapper.selectForUpdate(goodsId, locationId); if (stock == null) { // 首次入库，初始化一行 stock = new WmsStock(); stock.setGoodsId(goodsId); stock.setLocationId(locationId); stock.setQuantity(qty); stockMapper.insert(stock); } else { stock.setQuantity(stock.getQuantity() + qty); stockMapper.updateById(stock); } // 写流水，记录变动前后 WmsStockRecord record = new WmsStockRecord(); record.setGoodsId(goodsId); record.setLocationId(locationId); record.setChangeQty(qty); record.setType("INBOUND"); record.setCreateTime(new Date()); recordMapper.insert(record); } }

逻辑说明：整个方法包在@Transactional里，库存更新和流水写入要么都成功要么都回滚。selectForUpdate对应 SQL 的SELECT ... FOR UPDATE，在事务内锁住这一行，防止并发修改。参数qty做了正数校验，避免有人传负数把入库变成出库。

参数怎么调：如果并发量不大（中小仓库通常如此），行锁足够；如果 QPS 高，可以改用乐观锁版本号字段，更新时WHERE version = #{version}，失败就重试。rollbackFor = Exception.class不能省，否则受检异常不会触发回滚，这是血泪经验。

3.2 单据状态机：别让入库单卡在「待审核」

WMS 的单据有状态流转：待审核 → 已审核 → 部分入库 → 已完成 / 已取消。状态机写不好，就会出现「单子审核了但库存没加」这种玄学问题。我的做法是把状态变更收敛到一个方法里，用枚举定义合法流转：

public enum InboundStatus { PENDING, // 待审核 APPROVED, // 已审核 PARTIAL, // 部分入库 FINISHED, // 已完成 CANCELED; // 已取消 // 判断当前状态能否流转到目标状态 public boolean canTransferTo(InboundStatus target) { switch (this) { case PENDING: return target == APPROVED || target == CANCELED; case APPROVED: return target == PARTIAL || target == FINISHED || target == CANCELED; case PARTIAL: return target == PARTIAL || target == FINISHED; default: return false; } } }

逻辑说明：canTransferTo把合法流转规则集中在一处，service 层调用前先判断，非法流转直接抛异常。这样即使前端传了错误的状态值，后端也能拦住。参数上，PARTIAL可以自流转（多次部分入库），FINISHED和CANCELED是终态，不能再变。

3.3 接口设计：给小程序和 Vue 共用一套 REST 规范

后端接口要同时服务 PC 和小程序，所以返回结构必须统一。我一般用这样的响应体：

{ "code": 200, "msg": "success", "data": { } }

分页接口统一传pageNum、pageSize，返回total和list。小程序端因为网络可能不稳定，接口要做幂等——比如入库提交带一个前端生成的requestId，后端用它做去重，防止用户连点两次提交导致重复入库。这个requestId存 Redis 设 5 分钟过期即可，不需要落库。

4. 前端与小程序：Vue 后台和扫码端的实现要点

4.1 Vue 后台：路由、权限与打包进 Spring Boot

Vue 后台的骨架是登录页 + 布局页 + 各业务页。路由用vue-router，权限控制用路由守卫：登录后拿到角色，动态生成可访问的路由表。热搜里「vue路由」「vue插槽」「vue打包放进springboot中」都是高频问题，这里说打包这一步。

Vue 打包后是静态文件，放进 Spring Boot 的src/main/resources/static目录，然后配一个转发规则，让非接口请求都指向index.html：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 静态资源目录 registry.addResourceHandler("/**") .addResourceLocations("classpath:/static/"); } }

逻辑说明：前端路由是 history 模式时，刷新页面会请求后端，如果后端没有对应接口就 404。解决办法是在 Nginx 或 Spring Boot 里配置 fallback 到index.html。参数上，addResourceLocations指向打包产物所在目录，注意结尾的斜杠不能少。

4.2 微信小程序扫码端：登录与手机号获取

小程序端第一步是登录。流程是：小程序调wx.login拿 code → 传给后端 → 后端用 code 换 openid 和 session_key → 生成自己的 token 返回。热搜里「微信小程序登录获取手机号」也是常见需求，获取手机号需要用户点击授权按钮，后端拿code调接口解密，注意这个接口需要企业主体的小程序才能用。

// 小程序端登录 wx.login({ success(res) { if (res.code) { wx.request({ url: 'https://your-domain/api/wx/login', method: 'POST', data: { code: res.code }, success(r) { // 存 token，后续请求带上 wx.setStorageSync('token', r.data.data.token) } }) } } })

逻辑说明：wx.login的 code 只能用一次，且 5 分钟过期，所以必须马上传给后端。后端换 openid 时用的是小程序的appid和secret，这两个值放配置文件，不要写死在代码里。参数上，wx.request的域名必须在小程序后台配置为合法域名，否则真机调试会失败——这是新手最容易卡住的地方。

4.3 扫码入库：小程序调扫码 API 的完整链路

扫码是小程序端的核心。用wx.scanCode拿到条码内容，再调后端接口查商品或库位：

wx.scanCode({ onlyFromCamera: true, // 只允许相机扫码，防止从相册选图作弊 scanType: ['barCode', 'qrCode'], success(res) { // res.result 是扫到的内容，比如商品条码 wx.request({ url: 'https://your-domain/api/goods/byBarcode', data: { barcode: res.result }, header: { 'Authorization': wx.getStorageSync('token') }, success(r) { if (r.data.code === 200) { // 展示商品信息，让用户填数量 this.setData({ goods: r.data.data }) } else { wx.showToast({ title: '未找到商品', icon: 'none' }) } } }) } })

逻辑说明：onlyFromCamera: true强制走相机，避免有人从相册选一张条码图反复提交。scanType限定条码类型，减少误扫。参数上，res.result就是条码字符串，后端按条码查商品档案。如果扫的是库位码，就换成查库位接口，逻辑一样。

5. 避坑与排查：WMS 上线后最容易翻车的 5 个地方

5.1 库存对不上：先查流水再看主表

现象：盘点时发现系统库存和实物差几件。原因：多半是某次操作只更新了主表没写流水，或者流水写了但事务回滚了主表没回滚。解决：库存主表只作为「当前快照」，任何对账都以wms_stock_record流水为准，用流水SUM出来的数量去核对主表，差异行就是问题点。排查时按商品 + 库位分组查流水，比盯着主表看有效得多。

5.2 小程序真机请求失败：域名和 HTTPS 没配

现象：开发者工具里一切正常，真机预览接口全部报错。原因：小程序要求所有请求域名必须 HTTPS 且在小程序后台配置为合法域名，开发者工具可以勾选「不校验合法域名」绕过，真机不行。解决：把后端接口挂到有证书的域名上，在小程序后台「开发设置」里填 request 合法域名。本地调试阶段可以用内网穿透工具临时给个 HTTPS 地址，但上线必须用正式域名。

5.3 Spring Boot 打包后静态资源 404

现象：本地npm run dev正常，打包放进 Spring Boot 后页面白屏或 404。原因：Vue 打包的publicPath默认是/，如果部署在子路径下就找不到资源；或者 history 模式刷新 404。解决：vue.config.js里设publicPath: './'（相对路径），后端配 fallback 到index.html。另外确认打包产物确实复制到了static目录，Maven 打包时target/classes/static里要有文件。

5.4 并发入库导致数量错乱

现象：两个收货员同时扫同一商品入库，最终数量比实际少。原因：没用行锁或乐观锁，两个事务读到同一个旧值再各自加。解决：如 3.1 所述，用SELECT ... FOR UPDATE锁行，或加 version 字段做乐观锁。中小仓库并发低，行锁足够；如果锁等待严重，再考虑把库存扣减改成 Redis 原子操作 + 异步落库，但这样一致性要额外处理，不建议新手一上来就做。

5.5 单据状态乱跳：前端传了非法状态

现象：入库单从「待审核」直接变成「已完成」，跳过了审核。原因：后端接口没校验状态流转，前端传什么就存什么。解决：所有状态变更走 3.2 的状态机校验，非法流转抛异常。另外前端按钮要根据状态置灰，但后端校验不能省——前端可以绕过，后端是最后一道防线。

6. 进阶技巧：用库存流水做一套可追溯的对账报表

系统跑起来之后，真正体现价值的是「能查账」。我一般会在流水表基础上做两个视图或查询：一个是按商品 + 库位的实时库存，一个是按时间段的出入库汇总。实时库存可以直接查主表，但为了验证准确性，我会写一个对账 SQL，用流水汇总去比对主表：

-- 用流水汇总核对库存主表，找出差异 SELECT r.goods_id, r.location_id, SUM(CASE WHEN r.type = 'INBOUND' THEN r.change_qty WHEN r.type = 'OUTBOUND' THEN -r.change_qty ELSE 0 END) AS flow_qty, s.quantity AS stock_qty FROM wms_stock_record r LEFT JOIN wms_stock s ON r.goods_id = s.goods_id AND r.location_id = s.location_id GROUP BY r.goods_id, r.location_id, s.quantity HAVING flow_qty <> IFNULL(stock_qty, 0);

逻辑说明：这条 SQL 把每条流水的增减量按商品 + 库位汇总，再和库存主表比对，HAVING只输出不一致的行。参数上，type字段的取值要和代码里写入时保持一致，否则汇总会漏。建议每天凌晨跑一次，结果推送给管理员，差异行人工核查。

再进一步，可以给流水表加操作人、单据号字段，这样任何一笔库存变动都能追溯到「谁、在什么时候、因为哪张单子」改的。小程序端扫码时把操作人 token 带上，后端从 token 解析用户 ID 写入流水。这套追溯能力在客户投诉「货少了」的时候特别有用，能直接定位到具体环节，而不是全仓库翻一遍。

我自己踩过的坑是：早期图省事，流水表只记了商品和数量，没记库位，结果多库位场景下对账完全没法做，只能加字段重刷历史数据。所以表设计阶段宁可多留两个字段，也别等上线后补。做 WMS 这行，库存准不准是命根子，流水就是你的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取