电商仓库管理系统实战：数据模型、防超卖与拣货路径设计

电商仓库管理系统这六个字，我在过去几年里被问过不下二十次，问的人从日均几十单的小卖家到日发万单的腰部商家都有。有意思的是，他们真正想问的往往不是“这套系统长什么样”，而是“我这摊子到底该不该自己搞一套”。这篇文章就把这件事从头到尾拆开讲：一套能真正跑起来的电商仓库管理系统，业务上要覆盖什么、数据模型该怎么设计、库存并发怎么防超卖、拣货路径怎么算、上线时又会踩哪些坑。整套内容偏实战，代码和技术栈用的是国内电商团队最常见的组合，稍微有后端基础的读者可以照着落地，完全没写过代码的运营同学也能看懂每一环背后的业务逻辑。

1. 先把账算清：为什么仓库管理系统值得自己动手

1.1 三个反复出现的痛点：错发、超卖、找货难

先说我见过最典型的一类现场。某做家居百货的团队，日发一千多单，仓库里三个人靠经验找货，货架没有编码，商品按“大概在那边”摆放。大促前一天临时加了两个兼职，第二天错发率直接冲到 3%，退换货成本加上平台罚款，一天亏掉的钱比省下来的系统开发费多得多。这就是第一个痛点：没有库位编码，人就是唯一的索引，人一换，能力就清零。

第二个痛点是超卖。很多团队的库存是“下单减一”写在业务代码里，多个渠道共用一份库存，前端展示和实际扣减之间隔着几分钟的缓存，大促一开闸，同一个 SKU 卖出去的数量超过实际库存，最后只能一个个打电话道歉。超卖的本质不是代码写得烂，而是库存没有唯一真相源，各处都在自己算自己的一份账。

第三个痛点是找货难，也就是拣货效率。同样一千单，有的仓库两个人一天拣完，有的仓库五个人加班到半夜。差别不在人勤快不勤快，而在订单有没有被合并成波次、拣货路线有没有按巷道排序、拣货单上的库位号是不是按物理顺序打印的。这三件事做与不做，单均拣货行走距离能差三到五倍。

提示：判断自己是否需要一套正规的仓库管理系统，最简单的指标是“单均作业时间”。如果单人单小时处理量长期低于 30 单，且没有明显的人员熟练度问题，基本可以确定是流程和工具的问题，不是人的问题。

1.2 自研、买 SaaS、二次开发：三条路线的成本账

这是绕不开的第一个决策。我把三条路线的差异整理成了一张表，注意这里的数字是基于常见市场情况的估算，具体还要看你自己的单量结构。

我个人的判断标准很朴素：如果你的作业流程和市面上标准流程的差异超过 30%，就别硬套 SaaS 了。比如做生鲜的需要批次效期管理、做定制的需要按订单属性拆包、做跨境的需要多仓多币种，这些在通用 SaaS 里通常是加钱定制的功能，而自研反而更省事。

反过来，如果你只是标准的“进货、存货、卖货”，日均几百单，我强烈建议先用 SaaS 把业务跑顺，把流程跑明白了再考虑自研。我见过太多团队在流程还没定型的时候就开始写代码，结果系统上线时业务已经改了三版，代码全成了负债。

真正适合自研的信号通常有三个：单量增长快、现有工具按单收费已经比自研人力贵、有独一无二的作业流程。三个里占两个，就可以动手了。

2. 系统骨架怎么搭：领域划分与数据模型

2.1 五个核心域：商品、库存、库位、单据、作业

新手最容易犯的架构错误，是按“入库模块、出库模块、盘点模块”来切分。这么切在演示阶段很爽，但业务一复杂就崩：入库要扣库存、出库要扣库存、盘点也要改库存，三处逻辑各写一遍，早晚对不上。

正确的切法是按领域切，把“库存”抽成独立的服务边界。我通常划五个域：

• 商品域：SKU、条码、规格、包装、效期属性。
• 库存域：数量、批次、状态（可用、锁定、在途、残次）、流水。
• 库位域：仓库、区域、巷道、货架、层、位，以及库位的容量和属性（拣货位、存储位、退货位）。
• 单据域：入库单、出库单、调拨单、盘点单、退供单，以及它们的状态机。
• 作业域：任务下发、拣货、复核、打包、称重、交接。

这样划分之后，一条铁律就立住了：任何单据都不直接改库存，只能通过库存域的接口产生流水。库存表是唯一真相源，其他所有地方看到的数字都来自它。这条规则听起来简单，但它能解决 80% 的“库存对不上”问题。

2.2 核心表结构：库存、流水、库位、单据

先说库存表。很多系统的库存表只有一列 qty，这是灾难的开始。我建议至少拆成四列：总量、可用、锁定、在途。

CREATE TABLE wms_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sku_id BIGINT NOT NULL COMMENT '商品ID', warehouse_id BIGINT NOT NULL COMMENT '仓库ID', location_id BIGINT NOT NULL DEFAULT 0 COMMENT '库位ID，0表示仓级汇总', batch_no VARCHAR(64) NOT NULL DEFAULT '' COMMENT '批次号，无批次管理填空串', qty_total INT NOT NULL DEFAULT 0 COMMENT '实物总量', qty_available INT NOT NULL DEFAULT 0 COMMENT '可售可用', qty_locked INT NOT NULL DEFAULT 0 COMMENT '已锁定待出库', qty_in_transit INT NOT NULL DEFAULT 0 COMMENT '在途', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_sku_wh_loc_batch (sku_id, warehouse_id, location_id, batch_no), KEY idx_sku_wh (sku_id, warehouse_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存主表';

这里有几个设计细节值得展开。第一，location_id允许为 0，用来存“仓级汇总”，查询总量时不用扫全部库位。第二，批次号放进了唯一索引，做效期管理的品类必须这么做，否则同一个库位里的不同批次会混成一个数字。第三，qty_total和qty_available分开存，因为实物存在不等于可售，质检中的、冻结的、残次的都要从可用里扣掉。

再说流水表。流水表的原则是只增不改，永不删除。

CREATE TABLE wms_stock_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_no VARCHAR(64) NOT NULL COMMENT '业务单号', biz_type TINYINT NOT NULL COMMENT '1入库 2出库 3锁定 4释放 5盘盈 6盘亏 7调拨', sku_id BIGINT NOT NULL, location_id BIGINT NOT NULL DEFAULT 0, qty_change INT NOT NULL COMMENT '正负变动量', qty_after INT NOT NULL COMMENT '变动后可用数量', operator VARCHAR(32) NOT NULL DEFAULT '', remark VARCHAR(255) NOT NULL DEFAULT '', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_biz_no (biz_no), KEY idx_sku_time (sku_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存流水';

流水表的价值在排查阶段体现得淋漓尽致。任何时候库存对不上，按 SKU 加时间范围把这批流水捞出来，从最近一次盘点或者初始入库开始累加，看哪一笔的 qty_after 和下一笔的变动对不上，问题点立刻暴露。没有流水表的系统，排查库存差异基本靠猜。

库位表我通常设计成树形结构，用 parent_id 加 level 表示层级。

CREATE TABLE wms_location ( id BIGINT PRIMARY KEY AUTO_INCREMENT, warehouse_id BIGINT NOT NULL, parent_id BIGINT NOT NULL DEFAULT 0, loc_code VARCHAR(32) NOT NULL COMMENT '库位编码，如 A-01-03-2', loc_type TINYINT NOT NULL DEFAULT 1 COMMENT '1拣货位 2存储位 3收货位 4退货位 5残次位', capacity INT NOT NULL DEFAULT 0 COMMENT '容量，按件或按体积', aisle_no INT NOT NULL DEFAULT 0 COMMENT '巷道号，用于拣货排序', shelf_no INT NOT NULL DEFAULT 0 COMMENT '货架号', level_no INT NOT NULL DEFAULT 0 COMMENT '层号', status TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', UNIQUE KEY uk_code (loc_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库位';

aisle_no、shelf_no、level_no这三列是为了拣货路径排序准备的，编码里虽然也带了这些信息，但字符串排序在 A-10 和 A-2 之间会出问题，单独存成数字列最省心。

2.3 技术栈与部署：单体优先，别一上来微服务

技术栈上我建议务实一点。日均三千单以内，一套 Spring Boot 单体加 MySQL 加 Redis 就完全够用，前端 Vue 或者 React 都行，移动端用 PWA 或小程序，扫码枪当作键盘输入设备接入，开发成本最低。

具体组合我常用的是：后端 Spring Boot 3 加 MyBatis-Plus，数据库 MySQL 8.0，缓存 Redis 7，消息队列用 RocketMQ 或 RabbitMQ 处理异步任务（比如出库单生成后的库存锁定落库），前端 Vue3 加 Element Plus，部署用 Docker Compose 起三四个容器就够。

这里我要重点说一句：不要一上来就微服务。我见过一个日发三百单的团队，把系统拆成了七个服务，结果一次下单要跨四个服务调用，开发一个退货功能要改五个仓库，最后维护成本比业务本身还高。单体的边界只要划清楚（按前面说的五个域分包），后面真要拆的时候是水到渠成的事，因为领域边界本来就是清楚的。

至于容量估算，给你一个粗略的参考：MySQL 单表在千万级行以内、QPS 五百以内，配合合理的索引完全扛得住。库存表按 SKU 数量乘以库位数估算，一万个 SKU 配两百个库位，最坏情况两百万行，离瓶颈还远得很。真正需要提前考虑的是流水表，它增长最快，日发万单的仓库一天能产生十万级流水，一年就是三千万行，这时候要提前做按月的分区表或者冷热分离。

3. 关键链路的实现细节

3.1 入库上架：从预约到库位分配的完整链路

入库这条链路，标准流程是：预约到货 → 收货登记 → 质检 → 上架 → 库存入账。很多系统把“收货”和“上架”合成一步，短期看省事，长期看会出问题，因为收货数量对上架数量之间需要有个中间状态，否则货到了但还没放上架，库存到底算不算数？

我的做法是收货即入账，但入的是“在途转待检”状态，上架确认后才转成可用。这样既能保证账实有据，又不会让还没上架的货被卖掉。

库位分配是这条链路上唯一有点算法含量的地方。最朴素的策略是“随机找空位”，但这样做拣货时会疯掉。我一般用三层策略：

1. 优先同 SKU 聚合：如果这个 SKU 已经占用了某个拣货位且还有余量，优先放那里，减少拣货时的多库位行走。
2. 按 ABC 分类选区域：把销量前 20% 的 SKU 定为 A 类，固定放在靠近打包台的拣货位；B 类放中间区域；C 类放深处或者上层存储位。
3. 按体积和重量做约束：重货放底层，大件放端头，易碎品避开通道拐角。

容量计算这里给个可用的公式。假设某 SKU 日均出库量为 Q，补货周期为 T 天，安全库存系数为 1.5，则需要的拣货位容量为 Q × T × 1.5。比如日均出 40 件、两天补一次货，那拣货位至少要放 120 件。如果单个库位只能放 60 件，就得配两个拣货位，或者把补货周期压缩到一天。

提示：拣货位和存储位一定要分开。拣货位放小批量、高频次，存储位放大批量、低频次，补货动作由系统生成补货任务触发。这一条能把仓库的空间利用率提升 30% 以上，同时拣货速度明显加快。

3.2 出库拣货：波次、路径与拣货单生成

出库是整套系统里最考验设计的一环，因为它同时牵扯订单、库存、任务和现场作业。

流程上我按这个顺序走：订单下传 → 库存预占 → 订单池 → 波次生成 → 拣货任务下发 → 拣货 → 复核 → 打包称重 → 出库交接 → 库存实扣。注意“预占”和“实扣”是两次动作，预占发生在订单进来时（可用减、锁定加），实扣发生在出库交接时（锁定减、总量减）。这两步分开，才能支撑取消订单、改地址、部分发货这些现实需求。

波次怎么划，是有明确算法的。核心目标是最小化总拣货时间，而总拣货时间大致等于“行走时间 + 拣选时间 + 分播时间”。订单越合并，行走时间越省，但分播时间越长。我常用的经验参数是：单波次订单数控制在 20 到 50 单，SKU 去重后不超过 80 个。低于 20 单，行走浪费；高于 50 单，播种墙放不下，复核容易乱。

波次划分的规则可以组合使用：按承运商分（同一个快递的放一起，方便交接）、按时间窗分（截单时间近的优先）、按商品属性分（大件单独一波，避免和百货混拣）、按区域分（同一巷道的订单合并）。

拣货路径这块，很多人以为要上 TSP 求解，其实不用。仓库巷道通常是规则的网格布局，用S 型路径（也叫蛇形路径）就足够好，实现简单且效果稳定：从通道一端进入，沿一侧货架走到头，横移到下一巷道，沿另一侧走回来，如此往复。它的行走距离在最坏情况下比最优解多 10% 到 20%，但计算成本几乎为零，而且拣货员容易理解和执行。

代码上就是按巷道号升序、同巷道内按货架号排序，再按奇偶决定方向：

public List<PickingItem> sortBySPath(List<PickingItem> items) { // 先按巷道号分组 Map<Integer, List<PickingItem>> byAisle = items.stream() .collect(Collectors.groupingBy(PickingItem::getAisleNo, TreeMap::new, Collectors.toList())); List<PickingItem> result = new ArrayList<>(); boolean forward = true; for (Map.Entry<Integer, List<PickingItem>> entry : byAisle.entrySet()) { List<PickingItem> group = entry.getValue(); // 同巷道内按货架号排序，偶数巷道反向，形成蛇形 group.sort(Comparator.comparingInt(PickingItem::getShelfNo)); if (!forward) { Collections.reverse(group); } result.addAll(group); forward = !forward; } return result; }

拣货单打印时，库位号要按上面的顺序输出，并且字号要大，最好一行一个库位，拣货员扫一眼就能走。我见过太多系统把拣货单打成密密麻麻的表格，拣货员边走边找，效率直接腰斩。

复核环节我强烈建议上称重校验。打包完成后自动称重，和系统根据商品重量算出的理论重量比对，偏差超过阈值就拦截。这一招能挡住绝大部分错发和漏发，成本只是一台电子秤和一次串口对接，投入产出比高得离谱。

3.3 库存扣减：悲观锁、乐观锁、Redis 预扣的取舍

这是被问得最多的问题，也是超卖的根源。我把三种常见方案摆在一起对比。

我的实际选择是分层组合：日常订单走乐观锁，大促峰值走 Redis 预扣加异步落库。这样既保证了平时的数据强一致，又扛得住峰值。

乐观锁的核心 SQL 只有一句，但条件一个都不能少：

UPDATE wms_stock SET qty_available = qty_available - #{qty}, qty_locked = qty_locked + #{qty}, version = version + 1 WHERE sku_id = #{skuId} AND warehouse_id = #{warehouseId} AND location_id = #{locationId} AND batch_no = #{batchNo} AND qty_available >= #{qty} AND version = #{version};

执行后判断影响行数，等于 1 说明扣减成功，等于 0 说明要么版本冲突要么库存不足，此时不要盲目重试，先查一次当前库存，够再重试，不够直接返回失败。重试次数我一般设 3 次，超过就降级到同步锁或者直接失败，避免线程池被打满。

Redis 预扣的 Lua 脚本关键点是“判断和扣减必须在同一个原子操作里”：

-- KEYS[1] = stock:sku:{skuId} -- ARGV[1] = 扣减数量 local available = tonumber(redis.call('HGET', KEYS[1], 'available')) local qty = tonumber(ARGV[1]) if available == nil or available < qty then return -1 end redis.call('HINCRBY', KEYS[1], 'available', -qty) redis.call('HINCRBY', KEYS[1], 'locked', qty) return available - qty

扣减成功后再发消息异步落库，落库失败要能回滚 Redis，所以消息必须可靠投递，消费端必须幂等。这里的幂等键用业务单号加 SKU 加库位，落库前先查流水表有没有这个组合，有就跳过。

提示：无论用哪种方案，都要在数据库层再加一道兜底约束，比如qty_available >= 0的 CHECK 约束或者触发器。应用层的 bug 永远会有，数据库的约束是最后一道闸。

3.4 盘点：从动态盘点看库存差异怎么收敛

盘点不是为了数清货，而是为了让账实重新对齐，并且找出差异的原因。很多团队只在年底盘一次，盘完调平就完事，第二年照旧，这就是白盘。

我的做法是循环动态盘点：每天系统自动抽取一批 SKU 生成盘点任务，抽取规则是“近三十天有出入库且金额占比高的优先”，保证一个月内把高价值 SKU 全部覆盖一遍，低价值的长尾商品按季度覆盖。这样不需要停业，也不需要集中人力。

盘点任务分盲盘和明盘。盲盘不给盘点人看系统数量，适合正式盘点；明盘给看数量，适合快速复核。我一般要求第一次盲盘，差异超过阈值的做第二次明盘复核，两次结果不一致就交给主管裁决。

差异处理流程要严格：盘盈盘亏都必须生成调整单，记录原因分类（错发、漏记、破损、被盗、录入错误），并产生库存流水。调整单要审批，不能谁都能改库存，否则盘点就失去了意义。

差异原因的分析比调平更重要。我一般按月出一张表，看哪个原因占比高。如果“录入错误”占比高，说明收货环节的扫码校验不到位；如果“错发”占比高，说明复核环节有问题；如果“破损”集中出现在某几个库位，可能是摆放位置不合理。这张表每个月看一次，比任何管理会议都管用。

4. 从零跑起来：环境、代码与压测

4.1 环境准备与数据库初始化

本地起一套环境，我建议直接用 Docker Compose，省得在依赖上折腾。

version: '3.8' services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: wms123456 MYSQL_DATABASE: wms ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql - ./init.sql:/docker-entrypoint-initdb.d/init.sql command: --default-authentication-plugin=mysql_native_password --innodb_buffer_pool_size=1G --max_connections=500 redis: image: redis:7-alpine ports: - "6379:6379" command: redis-server --appendonly yes --maxmemory 512mb --maxmemory-policy allkeys-lru

innodb_buffer_pool_size这个参数值得单独说。默认值往往只有 128M，对于库存查询这种读多写少的场景，把这个值调到物理内存的 50% 到 70%，查询性能会有肉眼可见的提升。我实测过一个库存汇总查询，从 800 毫秒降到 40 毫秒，只改了这一个参数。

初始化脚本里除了建表，还要插入基础数据：一个仓库、若干库位、几个测试 SKU。库位编码建议按区域-巷道-货架-层的规则生成，比如A-01-03-2，这样人眼可读，程序也好排序。

4.2 核心接口实现：库存预占的完整代码

下面这段是订单预占库存的核心服务，包含了重试、幂等和流水记录，可以直接参考。

@Service @RequiredArgsConstructor public class StockOccupyService { private final StockMapper stockMapper; private final StockFlowMapper flowMapper; private static final int MAX_RETRY = 3; @Transactional(rollbackFor = Exception.class) public boolean occupy(Long skuId, Long warehouseId, Long locationId, String batchNo, int qty, String bizNo) { // 幂等：同一业务单号已处理则直接返回成功 if (flowMapper.countByBizNo(bizNo, skuId, locationId) > 0) { return true; } for (int i = 0; i < MAX_RETRY; i++) { Stock stock = stockMapper.selectOne(skuId, warehouseId, locationId, batchNo); if (stock == null || stock.getQtyAvailable() < qty) { return false; } int affected = stockMapper.occupyWithVersion( skuId, warehouseId, locationId, batchNo, qty, stock.getVersion()); if (affected == 1) { flowMapper.insert(StockFlow.builder() .bizNo(bizNo) .bizType(3) .skuId(skuId) .locationId(locationId) .qtyChange(-qty) .qtyAfter(stock.getQtyAvailable() - qty) .build()); return true; } // 版本冲突，短暂让出 CPU 后重试 LockSupport.parkNanos(1_000_000L * (i + 1)); } return false; } }

几个细节说明一下。幂等判断放在最前面，防止消息重投导致重复扣减。重试之间做了递增的短暂等待，避免多个线程在同一时刻反复碰撞。流水记录和库存更新在同一个事务里，保证要么都成功要么都回滚。

对应的 Mapper 方法就是前面那条带 version 条件的 UPDATE，注意返回值是 int，代表影响行数。

4.3 压测数据与调优记录

压测我用的是 JMeter，场景设计成“70% 查询库存、20% 预占、10% 出库确认”，模拟真实比例。

第一轮跑下来的结果是：500 并发下，预占接口的 P99 到了 1.2 秒，大量请求超时。排查下来两个原因，一是库存表缺少(sku_id, warehouse_id)的联合索引，查询走了全表扫描；二是乐观锁冲突率高达 40%，大量重试进一步放大了数据库压力。

改成联合索引后，查询耗时从 200 毫秒降到 3 毫秒。针对乐观锁冲突，我做了两件事：把同一 SKU 的预占请求按 hash 路由到固定的处理线程（类似分段锁的思路），把冲突率降到 8%；同时把重试策略从立即重试改成指数退避，减少无效碰撞。

第二轮压测：500 并发下 P99 降到 180 毫秒，1000 并发下 P99 是 420 毫秒，吞吐量稳定在 1800 TPS 左右。对于日发万单的仓库，峰值 TPS 通常在几十到一百的量级，这个余量已经很充足了。

提示：压测一定要用接近生产的数据量，至少十万级 SKU 和百万级流水。用几十条测试数据压出来的结果毫无参考价值，因为索引的选择性完全不同。

5. 踩坑实录：问题排查与上线迁移

5.1 库存对不上的六种典型场景速查表

库存差异是仓库系统的头号问题，我把遇到过的场景整理成了速查表。

这张表建议贴在运维群公告里，出问题时按“现象→原因→方法”三步走，比临时翻代码快得多。

我特别想强调的是对账任务。很多团队觉得库存实时一致就够了，不需要对账，这是错的。实时一致保证的是正常路径，对账保证的是异常路径。我一般会做一个每日凌晨跑的任务：按仓库维度汇总所有明细库位，和仓级汇总行比对，不一致就告警并自动修正，同时记录下不一致的 SKU 和时间点，方便第二天复盘。

5.2 性能与稳定性：几个容易被忽略的坑

第一个坑是长事务。出库确认的时候，如果在一个事务里既改库存、又更新单据状态、又发消息、又调外部接口，事务能持续好几秒，库存行被锁住，其他订单全部排队。我的做法是把事务范围压到最小，只包住库存更新和流水写入，其他动作通过事务提交后的事件异步处理。

第二个坑是消息重复消费。库存相关的消息一定要做幂等，用业务单号加操作类型作为唯一键，消费前先查。别指望消息队列的“精确一次”，那是理论上的东西，实际全靠消费端自己做。

第三个坑是缓存击穿。商品详情页大量读库存，缓存过期瞬间打穿到数据库。解决办法是热点 SKU 的缓存不设过期时间，靠后台定时刷新，或者用互斥锁保证只有一个线程回源。

第四个坑是大促前的库存预热。日发万单的仓库，大促峰值可能是平时的十倍，Redis 预扣的数据要在活动前提前加载好，并且设置一个降级开关，一旦 Redis 出问题能立刻切回数据库乐观锁。

5.3 上线切换：数据迁移与灰度策略

从老系统切到新系统，最容易出事的是数据迁移。我的经验是分三步走。

第一步是静态数据先迁，商品、库位、供应商这些不常变的数据提前一周迁完，迁完做一次人工抽查，每条数据都要能对得上。第二步是库存快照迁移，选一个业务低峰期（通常是周日凌晨），冻结所有出入库操作，导出老系统的库存快照，导入新系统，然后用实物盘点结果核对，差异逐条确认。第三步是单据切换，老系统里未完成的单据要么全部结掉，要么在新系统里重建，不要留悬空单据。

灰度策略上，我建议按仓库灰度而不是按订单灰度。先切一个仓库跑一周，观察库存准确率、订单履约时效、异常单比例三个指标，稳定后再切下一个。按订单灰度看着更平滑，但同一个仓库两套系统并行，库存同步会非常麻烦，得不偿失。

切换后的一周是关键期，我一般会安排人每天早晚各做一次全仓抽查，抽 20 个 SKU 核对账面和实物，同时盯着库存流水，看有没有异常的正负变动。这一周扛过去，基本就稳了。

提示：切换前一定要准备好回滚方案，包括老系统的数据在新系统运行期间如何同步回去。回滚方案不是形式主义，我见过切到一半发现问题、又没有回滚路径，最后只能停业两天手工理货的情况。

最后分享一个我自己每次上线都会做的小动作：在系统里埋一个“操作留痕”的日志，记录每一次库存变更的操作人、来源 IP、操作时间和变更前后的值。这个日志平时没人看，但每次出了问题，它就是最快定位问题的工具。毕竟仓库系统的问题，十有八九不是代码算错了，而是某个环节的人做错了动作，而留痕能让你在两分钟内找到那个动作。