1. 三端仓储系统的项目定位与需求拆解做仓储管理系统这些年最大的感触是库存数据永远跟不上实际货位仓管员每次盘点都要拿着纸质单据来回跑老板想看实时库存还得打电话催人截图。我这次做的这套系统核心就是解决这三个老大难问题——用微信小程序、Web管理端、PC客户端三端协同再加上人脸识别做实名操作确认把仓库的进销存全流程管起来。先明确一下这套系统的适用场景。小型电商仓、生产企业的原料仓、第三方云仓的分拣区只要SKU数量在几百到几万之间日出入库单量不超过几千笔这套方案完全够用。要是大型自动化立体仓库那得上WMS加自动化设备对接不是这个系统要解决的问题。系统分成三条使用链路。PC客户端部署在仓库现场连接人脸识别摄像头、标签打印机和扫码枪负责收货、上架、拣货、发货这些高频操作。Web管理端给办公室的运营、采购、财务用看报表、调库存、审批单据。微信小程序给老板和业务员用手机上查库存、看销售趋势、处理紧急调拨。三端共享同一套数据和业务逻辑只是交互形式和功能侧重不同。核心关键词拆解一下人脸识别不只是门禁打卡更重要的是“操作留痕”。谁在什么时候做了什么操作刷脸确认后才算数杜绝代扫、乱记账。进销存采购入库、销售出库、库存调拨、盘点盈亏、退换货五个核心单据流转。三端协同同数据源、同业务逻辑、不同展示终端而不是做了三个独立软件。这套系统的价值就在于把“账实相符”这件事从制度约束变成系统强制。我对接过的仓库里至少有三分之一存在库存准确率低于80%的问题原因不外乎入库时漏扫、出库时拿错货、盘点时凭感觉改数。人脸识别加扫码校验等于给每一步操作上了一道双保险。2. 技术选型和整体架构设计2.1 三端的技术栈选型逻辑先说PC客户端。仓库现场的电脑配置普遍不高很多还是几年前的老机器而且经常同时开着浏览器、ERP客户端、聊天软件。所以PC端我用的是C# 的WinForms方案打包成单机exe不依赖浏览器不占太多内存数据通过HTTP方式走内网API通信。WinForms的表格控件处理单据明细、批量录入、扫码连打这些场景比Web端顺手太多。2.2 人脸识别的接入方案选型人脸识别是这套系统里最容易被低估的模块。很多人以为就是调一个SDK拍个照比对一下实际落地时全是细节。我用的方案是离线优先PC客户端接入USB摄像头通过某国产算法包做人脸检测和特征提取识别结果与员工库比对后返回工号和姓名整个比对过程在本地完成不依赖外网。这套联调方案的好处是断网也能用——仓库网络经常抽风如果人脸识别还要连云端那仓库自动停工。离线方案下人脸底库在PC端存一份加密副本每天由管理端同步一次增量更新。至于打卡记录和操作日志先存在本地SQLite网络恢复后自动补传不外泄、不重叠。2.3 Web管理端和接口层的技术方案Web端选择比较多元。我最终选用的方案是前后端分离后端采用Java生态打包为独立可执行文件内置Web服务提供RESTful API前端使用Vue框架构建后合并部署在同端口下管理后台直接访问一个地址即可。数据库用关系型数据库标准版本5年数据量以内性能都够。库存表用了乐观锁版本号字段并发出库时防止超卖。Redis做了缓存但只缓存热点数据——比如商品信息、库位状态核心的库存数字永远以数据库为主避免缓存与DB不一致的问题。2.4 微信小程序端的定位与局限性微信小程序既然是给老板和业务员用的就没做重逻辑。小程序端只负责三件事查库存、看报表、审批单据。真正要扫码收货、打标签、盘点的操作小程序完全做不了因为微信的JS环境调不了蓝牙打印机摄像头扫码也只是调起微信内置扫一扫不可能接外设。这里给后来人一个建议不要试图把小程序的权限做大。微信的审核规则对“人脸识别”这种能力卡得很严个人小程序根本拿不到接口权限企业小程序还要提供真实场景证明。所以在小程序端我只做了“结果展示”和“审批动作”把人脸识别限制在PC客户端这里是受控的物理环境。3. 核心功能模块的拆分与实现3.1 人脸识别模块不止是开门更是防抵赖人脸识别模块我设计成三个使用场景场景一是库房门禁。员工刷脸开门系统记录入场时间和PC客户端的上机操作绑定。如果你刷了门禁但10分钟内没有进行的系统操作系统把门禁记录标记为异常。这个逻辑主要是防止“人进了但账不动”——很多库存丢失并不是偷而是有人开了门随手拿了东西没记账。场景二是关键单据的人脸确认。出库单、盘点单这种影响库存数据的关键操作在提交时二次刷脸确认。别看这一步多花了5秒钟盘点差异的追责效率提升了不止一个量级。以前盘点错了要查录像、问班组现在系统里直接记录“谁在什么时间确认过这份盘点差异单”谈话成本就低多了。场景三是无感登录取代账号密码。仓库员工流动性大密码经常泄露工牌可以互相借但脸很难替换。员工走到摄像头前自动识别识别通过直接进入系统不用再输密码。配合活体检测能防住戴照片、翻拍视频这种低级攻击手段。3.2 进销存核心流程从单据到库存的数据闭环进销存的本质就一条线任何库存变化都必须有单据依据。这条线拆开是四个核心单据和三个衍生单据核心单据采购入库单供应商送货→仓管员收货→扫码确认→库存增加销售出库单业务员开单→拣货员按单拣货→刷脸复核→库存减少库位调拨单A库位→B库位→两边库存同时变化总量不变盘点单盘盈盘亏走向差异审核→审核通过才调整库存衍生单据退货申请单销售后退货需先质检再回库报损单效期过期、破损等原因经审批后库存扣减调拨申请单跨仓库之间调货联动对方仓库的入库每个单据的状态机也很简单草稿→已提交→流程中→已完成。关联后续动作的单据默认草稿状态比如采购入库单只有点了“完成收货”才会真正增加库存。这个设计避免了一个常见问题“单子创建了但货没到库存却已经加了。”3.3 库存台账与预警把账算清楚库存数量是最容易实现的但真正需要花心思的是库存台账的设计。我维护了四张表当前库存表一个SKU在一个库位只有一条记录只存数量和版本号流水表每一次变化都在这里追加一条记录永不修改删除单据表流水对应的业务单据关联人和时间日结表每天凌晨跑批汇总用于报表和财务对账这个设计下任何时间的库存数据都能追溯。比如有人问“上个月15号这个SKU的库存为什么是零”操一行SQL按日期、按单号、按流水号一层层追下去6秒就能说清楚。预警规则我做了四类库存下限预警低于安全库存自动生成补货建议、库存上限预警呆滞料占用库位、效期预警近效期商品提前90天提醒、零动销预警90天无出入库记录提示处理积压。预警不是弹窗就算了而是生成待办任务推给小程序端审批人手机上就能处理。3.4 标签体系与库位管理现场作业的支撑仓库现场作业离不开标签。入库时打商品标签品名、SKU编码、批次号、效期和库位标签仓库号、巷道号、货架层、位号。扫码枪或者PDA扫商品标签再扫库位标签系统自动完成绑定操作。这里有个细节库位编码的规则设计很重要。我用的编码规则是“库区-通道-货架-层-位”比如A区-03通道-H货架-第二层-05位。这套编码规则中学生练习可能觉得啰嗦但真到仓库里就会发现只要员工报出“A03-H2-05”老仓管员头顶都能画出位置不需要看系统也能找到货。千万别用纯流水号库位找了半年货的老仓管离职后新人完全抓瞎。4. 实操过程与关键环节实现4.1 开发环境和工程结构准备工程目录划分比较常规客户端文件夹是PC端源码服务端文件夹是后端API服务仓库管理后台是Web端前端项目小程序目录是小程序源码数据库脚本单独建了目录存放初始化建表和初始配置数据。本地开发电脑配了内部测试服务器装了数据库和缓存服务。PC客户端调试时连本机API地址Web端用反向代理转发请求。这里有个建议一上来就把测试环境域名和线上环境域名区分开不要混用否则真上线时改配置改到怀疑人生。4.2 数据建模和接口设计数据表设计原则就是“一次建模一套服务三端通用”核心表如下员工表员工编号、姓名、人脸特征向量、角色、状态仓库表多仓库支持仓库编号、名称、地址商品表SKU、品名、规格、单位、默认库位、安全库存库存表仓库、库位、SKU、数量、可用数量、锁定数量、版本号入库单和明细表出库单和明细表调拨单和明细表盘点单和明细表批次表批次号、生产日期、效期、供应商关键接口设计登录和鉴权接口支持账号密码和人脸识别两种方式人脸特征注册接口录入底库人脸比对接口提取特征与底库比对返回命中记录库存查询接口支持SKU、库位、库存状态多维度查询出入库开单接口事务保证单头、明细、库存更新三步原子性盘点提交接口报表统计接口日结、月结、出入库排名、供应商绩效等接口设计上没有用复杂的微服务架构全部走单体服务。仓库系统最大的并发场景也就是早晚高峰期几百个请求同时打进来单体服务加合理索引绰绰有余没必要为了架构好看引入分布式的复杂度。4.3 PC客户端核心代码实现思路PC客户端启动时有三大模块登录模块、业务操作模块、同步模块。人脸识别核心逻辑的伪码层面是这样加载本地特征库到内存 循环读取视频帧 检测人脸区域 若检测到人脸且处于可识别状态 提取特征向量128维浮点数组 与特征库逐一计算余弦相似度 取最高分若高于阈值则判定识别成功返回对应员工信息 活体检测检测眨眼动作与头部轻微转动 识别成功则退出循环进入系统主界面界面布局采用左侧菜单加右侧工作区的经典模式左侧分别是首页、入库管理、出库管理、库存查询、盘点管理、报表中心、系统设置。每个操作界面都放一个“人脸确认”按钮点按钮弹起摄像头识别成功后按钮变为绿色高亮标识“该操作已实名确认”。打印机控制用的是标签打印类库直接在里面对接标签打印机指令集。模板设计支持自定义字段位置可以调整字体大小、条码宽度、标签间距。这些功能Web端做起来很痛苦但PC客户端里就是现成控件直接拖拽绑定字段搞定。4.4 Web管理端实现细节Web管理端的核心页面仪表盘今日出入库笔数、库存总量、预警数量、待办审批数量商品管理SKU新增、编辑、上下架管理支持批量导入采购管理供应商、采购订单、收货确认、采购报表跟踪销售管理客户、销售单、发货确认、销售趋势图库存管理实时库存查询、库存流水、效期管理、批次追踪员工与权限员工账号、角色权限、人脸底库管理系统配置仓库库位维护、打印机参数、单据编号规则权限模型上我建议控制在4个角色就够用系统管理员全部权限、仓库操作员出入库与盘点、业务审核员单据审批与报表、只读查看老板、财务。不要动不动就做细粒度权限控制字段级权限对中小型仓库是自找麻烦上线后维护成本远超收益。4.5 小程序端实现要点小程序端页面极简设计首页是动态看板库存总量、今日入库、今日出库、预警数、待办审批数下面分别进入库存查询、单据审批、报表中心。发表单审批的时候可以看明细、看附件图、选择通过或驳回操作逻辑和微信审批流程很像员工上手基本零成本。小程序端用的UI组件是自带的基础组件没有引第三方库。原因还是稳定性优先第三方组件库版本升级容易出问题而仓库管理系统的核心诉求是可用性不是花哨的界面效果。配置小程序时需要注意域名白名单所有请求域名都需要在小程序后台配置白名单必须走HTTPS且ICP备案要一致。开发时如果本地调试需要在小程序后台勾选“不校验合法域名”。5. 三端数据同步与一致性方案三端共用一套API数据天然同源但这不代表没有一致性挑战。5.1 高并发出库场景的防超卖出库操作核心风险是多人同时拣同一SKU时库存扣超。我在库存表加了版本号字段更新库存在SQL层面增加“版本号匹配”条件不匹配则更新失败。然后让前面接口带着身份标识重新查询当前版本展示给操作人员确认“库存已经变化请刷新后重试”。仓库系统不是电商秒杀扣减库存加个乐观锁就完全够用。悲观锁在这个场景反而会导致锁等待拖慢现场作业速度。5.2 PC端离线时的数据同步前面提到PC端本地有SQLite作为离线缓存所有业务操作都先写本地再异步推给服务端。这里需要注意幂等设计本地每条操作生成全局唯一单号服务端接收时先查单号是否已存在存在则直接返回成功不重复处理。实现业务操作时同步了三个维度基础数据同步商品、员工、库位每天拉取增量业务流水同步本地操作实时推送人脸特征库同步每日增量更新离线时间超过3天系统会强制弹窗提示“请尽快联网同步”并限制发布新单据防止数据差异过大。5.3 库存锁定的特殊场景出库单开了单但拣货员还没拣完这时候如果盘点或者调拨同时在做会造成对同一SKU状态的不同认知。为此我在库存表加了锁定数量字段开单时锁定拣货完成时解锁扣减取消单据时直接解锁。这样设计下“可用库存”的计算逻辑变成可用库存总库存-锁定数量。任何查询界面显示的都是可用库存避免出现“账面上有货但实际拣不出来”的尴尬。6. 常见问题与排查技巧实录6.1 人脸识别在暗光环境下的改进仓库现场普遍灯光条件差特别是货架深处和卸货区人脸识别误识率直线上升。实测中暗光环境下检出率会从98%掉到70%左右这个差距非常致命。解决的招数摄像头选带补光灯的型号人走近时红外补光自动打开活体检测阈值在暗光下稍微降一点避免因为运动模糊导致的误拒调整特征比对阈值从默认的0.6降到0.55记得误识风险会略增——权衡之下仓库场景更关注通过率6.2 扫码枪乱扫导致串货问题模拟测试阶段发现一个坑扫码枪扫的商品标签和库位标签如果操作员不小心先扫了着其他步骤的条码数据串位了。排查下来是扫码枪的输入模式问题——它默认是模拟键盘在输入框失焦情况下扫到的条码可能会被Windows聚焦到其他控件上。解决方法是全局做扫码输入过滤只在“期望扫码”的状态下响扫码枪输入其他时候一律忽略。这个机制可以在代码层面用焦点管理实现。6.3 微信小程序上线审核被拒的踩坑微信小程序后台审核要求提供“人脸识别”的资质证明而我只有P C端的离线方案小程序里没有人脸识别功能审核员误判为“涉及人脸识别功能未授权”被拒了两次。解决方案是在小程序描述里明确写明本小程序不采集人脸信息所有涉及人脸识别的操作在PC客户端本地完成。同时在前端代码中彻底移除人脸相关字样审核顺利通过。6.4 云服务器与本地部署的取舍最后说一下部署。很多仓库内网环境复杂数据敏感度又高不适合上云。我推荐混合部署核心库存数据库位于本地机房管理API同时部署本地云端或公司总部的报表服务通过专线或加密通道拉取数据。小程序端只能访问公网API所以公网API只做数据展示和审批不存储核心业务数据。如果预算有限可以用一台大内存的本地PC装数据库和API服务加公网穿透方案但防并发能力会弱一些适合日单量很小的微型仓库。这个方案能省好几千成本但只能撑住小规模使用。7. 最后再分享几个实操中的经验细节建这个系统踩过的坑太多了挑三个最值得说的收尾。第一个经验不要过度设计。一开始我给系统设计了多仓协同、工序流转、承运商管理、计费模块结果团队开发了三个月核心进销存模块反而因为需求没排上期被迫压缩排期。后来砍到只剩核心出入库加盘点项目才能上线。仓储系统的核心永远是账实相符其余功能都是锦上添花。第二个经验成人脸识别不要忽视“人事异动”流程。员工离职后底库要同步删除否则离职员工刷脸还能开门这是安全隐患。但这个操作是最容易被忽略的流程我特意在系统里设置了“离职员工清理”定期任务每月自动拉取员工状态对离职超30天但底库未清除的记录发预警。第三个经验跟仓库一线员工多混几天比读十本书都有用。系统做出来好不好用不是看UI多漂亮而是看会不会增加仓管员的操作量。我第一次上线时每个出库单都要填写8个字段仓管员骂到不行。后来去仓里跟了一整天把字段砍到只剩SKU、数量、库位三个必填其他全部自动带出或默认值效率提升了非常多。这套系统做完后我又迭代了三个版本目前仓库库存准确率保持在99.5%以上盘点和月结对账时间从原来的两三天缩短到半天。如果你也在做类似的三端仓库管理系统希望这篇东西能帮你少踩几个坑。每一条经验都是真金白银是算法跑不出来的现场手感。