去年我接手了一个食品流通企业的WMS改造项目，对方的仓库主管老陈在第一次沟通会上就倒苦水：“系统确实推荐了货位，但我们的拣货员根本不看，因为按系统推荐，A区最旧批次的货在货架第四层最深处，而B区新一个月的批次就在通道口。一笔出库单跑下来，光搬运就多花40分钟。”这个场景让我重新审视了一个被无数技术文章写烂了的命题：FIFO出库货位推荐，本质上不是一个排序问题，而是一个业务决策问题。单纯用ORDER BY生产日期排出来的结果，在真实仓库里可能是一份无法执行的推荐清单。
过去五年我参与过4个WMS系统的FIFO推荐模块设计，从自研ERP里的简单批次排序，到支持多目标优化的智能推荐引擎，踩过的坑足够装满一个中型仓库。这篇文章要讲的，不是那句“按生产日期升序排列即可”的正确废话，而是在真实业务约束下，如何设计一套既能执行FIFO原则、又不被拣货员骂娘、还能在库存超50万行时保持亚秒级响应的货位推荐系统。我会把数据库设计、核心算法、异常场景处理和性能取舍全部拆开来讲，同时指出那些竞品文章里要么回避、要么压根没意识到的隐藏问题。
先给一个明确的结论：单纯按批次先后顺序推荐货位，在超过70%的真实仓库场景中会失效。这不是危言耸听，而是我在多个项目现场验证过的数据。
假设某物料M有三个在库批次，信息如下：
| 批次号 | 生产日期 | 库存数量 | 所在货位 | 货位区域 | 距拣货口距离 |
|---|---|---|---|---|---|
| B20240115 | 2024-01-15 | 200件 | A-04-03 | A区深处 | 约80米 |
| B20240320 | 2024-03-20 | 150件 | C-01-01 | C区通道口 | 约15米 |
| B20240510 | 2024-05-10 | 300件 | B-02-02 | B区中部 | 约40米 |
按纯FIFO逻辑，系统会推荐A-04-03货位，因为B20240115批次最早。但实际情况是：拣货员如果去A区深处取货，需要操作高位叉车穿过两条窄通道，仅设备调度和行驶时间就要增加15分钟。而C-01-01货位的B20240320批次只晚生产两个月，在食品保质期24个月的背景下完全可接受。系统推荐了一个“数学正确”但“运营错误”的结果。
从业务角度看，一个真正可用的FIFO货位推荐系统，需要同时满足三层约束：
绝大多数技术文章只处理了第一层，即实现“按日期排序”，然后就在代码块里收工了。但第二层和第三层才是WMS产品经理和仓库主管真正头疼的问题。而第三层处理不好，整个推荐系统就是一座空中楼阁。
做了这么多项目之后，我有一个判断：FIFO推荐算法的优劣，不取决于排序逻辑写得多精妙，而取决于异常处理规则覆盖得多全面。一个只有正常推荐路径、没有异常分支的系统，上线第三周就会因为一个锁定货位、一次临期预警或一次零头不够的情况而崩溃。后面我会详细拆解这四类异常场景，这是本文与其他同类文章最大的差异所在。
聊完业务逻辑，我们进入技术实现。数据库表设计是整个推荐系统的基础，但在真实的项目经历中，我见过的因为库表设计缺陷导致FIFO推荐失效的案例，比算法写错的案例多得多。
一个标准的FIFO货位推荐系统至少需要三张核心表：
（1）批次表（batch_info）
| 字段名 | 类型 | 说明 | 设计要点 |
|---|---|---|---|
| batch_id | VARCHAR(32) | 批次唯一标识 | 建议使用业务编码规则生成，不要用自增ID |
| material_id | VARCHAR(32) | 物料ID | 与物料主数据关联 |
| production_date | DATE | 生产日期 | 这是FIFO排序的第一优先级字段 |
| inbound_date | DATETIME | 入库时间 | 当生产日期相同时的排序第二优先级 |
| expiry_date | DATE | 保质期截止日 | 用于临期判断，不是用于排序 |
| batch_status | TINYINT | 批次状态 | 0正常/1临期/2过期/3冻结，影响推荐的强制规则 |
（2）库存表（inventory）
| 字段名 | 类型 | 说明 | 设计要点 |
|---|---|---|---|
| inventory_id | BIGINT | 库存记录ID | 自增主键 |
| material_id | VARCHAR(32) | 物料ID | 索引字段 |
| batch_id | VARCHAR(32) | 批次ID | 关联批次表 |
| location_id | VARCHAR(32) | 货位编码 | 关联货位表 |
| quantity | DECIMAL(18,4) | 可用库存数量 | 注意：是“可用”库存，不是账面库存 |
| locked_qty | DECIMAL(18,4) | 锁定数量 | 拣货中/质检中占用的数量 |
| scattered_flag | TINYINT | 零头标记 | 1表示该货位该批次为零头，优先出清 |
（3）货位表（location）
| 字段名 | 类型 | 说明 | 设计要点 |
|---|---|---|---|
| location_id | VARCHAR(32) | 货位编码 | 建议带有区域、通道、层数信息 |
| zone | VARCHAR(16) | 库区 | A区/B区/C区等 |
| aisle | VARCHAR(8) | 通道编号 | 用于计算距离 |
| tier | TINYINT | 层数 | 底层便于拣货，高层需要叉车 |
| distance_from_dock | INT | 距发货口的理论距离 | 单位米，可以手工维护或自动计算 |
| location_type | TINYINT | 货位类型 | 0普通/1高位/2地堆/3流利架，影响拣货方式 |
这些是我在实际项目中真实遇到过的问题，每一个都曾经导致推荐结果出错：
坑一：使用入库时间代替生产日期排序。不少早期系统的批次表里根本没有production_date字段，因为上线时业务方说“按入库先后出就行”。但后来出现了补货入库、退货重新入库等场景，入库时间完全不能代表生产先后。我见过最离谱的案例：一批2023年6月生产的退货商品在2024年1月重新入库，系统错误地将其排在了2023年12月正常入库商品之后。
坑二：库存表里没有区分可用库存与锁定库存。如果直接按库存表的quantity字段推荐货位，当某个货位的库存正在被其他拣货任务锁定但尚未扣减时，系统会推荐一个实际上没有可用库存的货位。正确做法是：推荐逻辑必须使用 quantity – locked_qty 作为实际可用量，并且在推荐结果返回前端之前再次校验库存状态。
坑三：货位距离数据缺失或失真。很多WMS的货位表里没有distance_from_dock字段，或者有但上线后从未维护。没有距离数据，推荐算法就无法在批次优先级和拣货效率之间做权衡。我在一个项目中花了三天时间，带着仓库主管走了一遍所有通道，手工录入了每个货位到发货口的步数，虽然土，但管用。
坑四：同一个货位存放多个批次时没有区分策略。这是物理布局的问题反馈到系统逻辑上。如果一个货位里混放了三个不同批次的同一物料，系统推荐这个货位时，拣货员拿到的是三个批次的实物混在一起，根本无法执行FIFO。解决方向有两个：一是系统层面在入库时就约束同一货位只能存放一个批次；二是如果已经混放，推荐时必须标记“此货位批次混杂，建议人工确认”。
坑五：忽略零头优先出清。一个托盘上只剩3件零头，旁边另一个托盘是同批次整托200件。从FIFO角度看批次相同、生产日期相同；但从仓库管理角度看，零头应该优先出清以释放货位。如果在推荐逻辑里没有处理零头优先，会导致仓库里零头货位越积越多。
坑六：没有考虑仓库作业波次的影响。WMS通常会按波次批量生成拣货任务。如果FIFO推荐是在单任务级别运行，而不考虑同一波次内其他任务对同一货位的争抢，就可能出现两个任务被推荐到同一个货位、但实际库存只够一个任务的情况。需要在推荐层面对波次内的货位分配做全局预占。
讲完数据基础，我们进入核心算法部分。我会从最简单可用的版本开始，逐步叠加复杂度，直到能够处理真实仓库中的大部分情况。
这是市面上90%的文章止步的地方。逻辑非常简单：按物料ID分组，组内按生产日期升序、入库时间升序排列，取最早的那条库存记录作为推荐结果。用SQL窗口函数实现大致如下：
WITH ranked_inventory AS (
SELECT
i.inventory_id,
i.material_id,
i.batch_id,
i.location_id,
i.quantity - i.locked_qty AS available_qty,
b.production_date,
b.inbound_date,
ROW_NUMBER() OVER (
PARTITION BY i.material_id
ORDER BY b.production_date ASC, b.inbound_date ASC
) AS priority_rank
FROM inventory i
INNER JOIN batch_info b ON i.batch_id = b.batch_id
WHERE i.material_id = #{targetMaterialId}
AND i.quantity - i.locked_qty > 0
AND b.batch_status = 0
)
SELECT * FROM ranked_inventory WHERE priority_rank = 1;这段SQL在逻辑上没有错，但它只能处理“没有任何例外情况、仓库布局完全均匀、所有货位取货成本相同”的理想场景。现实世界中，这种场景几乎不存在。
我从第二个项目开始，改用了一套评分模型。核心思路是：不再按单一维度排序，而是对每个候选货位计算一个综合得分，按得分降序推荐。评分维度和权重如下：
| 评分维度 | 权重 | 计算方式 | 说明 |
|---|---|---|---|
| 批次时效分 | 40% | 基于生产日期距今的天数，越久分数越高 | 保证FIFO主方向不变 |
| 货位距离分 | 25% | 基于distance_from_dock，距离越近分数越高 | 控制拣货效率 |
| 零头优先分 | 15% | scattered_flag=1时额外加分 | 促进零头出清 |
| 货位类型分 | 10% | 地堆>流利架>低层货架>高位货架 | 降低拣货难度 |
| 临期加权分 | 10% | 距离保质期不足30天时大幅加分 | 防止过期损失 |
这套评分体系在实践中运转良好。以本文开头老陈的案例来说，同一物料三个批次的得分会是：
系统会推荐得分为78分的B20240320批次，而不是纯FIFO规则下的B20240115批次。老陈对这个结果很满意：“这个推荐我会让拣货员执行，因为它省下来的时间比多放两个月保质期值钱。”
权重不是拍脑袋定的。我在项目中的做法是：先跑两周的实际订单数据，统计系统推荐的采纳率和拣货效率，然后逐步调整权重。具体操作如下：
（1）上线前用历史订单做回放测试，观察推荐结果在多大程度上偏离了“最旧批次”；
（2）上线后第一周以“建议模式”运行（系统推荐但允许拣货员手动覆盖），收集所有被覆盖的推荐记录，分析覆盖原因；
（3）如果覆盖原因是“推荐货位太远”，则适当提高距离分权重；如果覆盖原因是“批次太老但货位太远”，则说明权重分配合理，不需要调整；
（4）每两周做一次权重微调，直到采纳率稳定在85%以上。
这里有一个重要的经验：不同物料分类可能需要不同的权重方案。保质期敏感型物料（生鲜、药品）应该提高批次时效分和临期加权分的比重；体积大、搬运成本高的物料应该提高货位距离分和货位类型分的比重。我在一个同时经营食品和家居用品的客户的系统中，为两类商品维护了两套权重参数。
这一节是本文最核心的部分。在日常技术文章里，这些场景几乎从未被认真讨论过。但根据我四个项目的统计，异常场景在实际运行中发生的概率约为18%-25%，也就是说每四五次推荐就可能触发一次异常处理。如果这些分支没有处理，系统就不是“偶尔出错”，而是“频繁失效”。
问题描述：系统推荐了货位L-A，但该货位的库存正在被另一个并发拣货任务锁定（locked_qty > 0），或者推荐算法执行时读取到的库存快照已经过期，实际可用库存已经变成0。
常见错误做法：直接跳过这个货位，推荐下一优先级。这种做法的问题在于，可能引发连锁反应：如果第二优先级的货位库存也不够，会一路跳过N个货位，最终推荐一个距离远、批次新、完全不符合FIFO原则的货位。
我采用的解决方案：三级降级推荐策略。
这个三级策略的关键设计是：不到万不得已不跨越批次。因为跨越批次意味着违背了FIFO的底层原则，必须有明确的记录和审批。
这是我从一个第三方仓储项目里学到的教训。该仓库在早期的入库流程中没有强制“一货位一批次”的规则，导致同一个货位上常常堆放了两到三个不同批次的同种商品。当系统推荐这个货位时，拣货员面对的是无法区分批次的混合库存。
系统层面的补偿方案有两个：
方案A（信息提示）：在推荐结果中标记该货位为“多批次混放”，并列出混放的所有批次号，让拣货员根据实物标签自行判断。这个方案成本最低，但把压力转移给了现场作业人员。
方案B（系统拆批）：在WMS中维护一张“货位内批次分布子表”，记录每个货位内部每个批次的预估数量。入库时通过RF扫码确认每个托盘/箱子的批次和数量，系统据此维护子表。出库推荐时，即使推荐了混放货位，也能精确到“取货位A-04-03、批次B20240115、数量30件”。这个方案效果好但实施成本高，需要入库流程的严格配合。
我在项目中通常先上方案A作为快速止血，然后推动仓库改造入库流程、逐步切换到方案B。一个现实的时间线是：方案A两周内上线，方案B需要两到三个月的流程改造。
在保质期管理的行业中，临期物料不能简单地参与正常评分排序，而需要一套强制推荐机制。在批次表的batch_status字段里，我已经设计了专门的“临期”状态。当某批次的batch_status被定时任务更新为“临期”（通常距保质期截止日还有30天或总保质期的10%时触发），它的推荐逻辑彻底改变：
这套机制在一个食品企业的项目里成功拦截了价值约12万元的即将过期商品。该企业此前每年因过期报损的金额约为35万元，上线这套系统后第一年降到了8万元。
场景描述：系统推荐了一个零头货位（只有10件库存），但出库单据需要30件。这10件取走之后，剩下的20件需要从哪一个批次、哪一个货位取？
这个问题看起来简单，但它是FIFO推荐与库存分配交叉的核心问题。如果处理不当，会出现“第一推荐货位取10件，第二推荐货位又从新批次取了20件，导致旧批次的整箱库存被跳过”的情况。
我的处理逻辑如下：
（1）当推荐货位的可用库存小于需求数量时，该货位全量分配，剩余需求量带入下一轮推荐；
（2）下一轮推荐的搜索范围仍然从最旧批次开始，不会因为第一轮已经推荐过旧批次就跳过去，除非旧批次的所有货位库存已经用尽；
（3）最终返回给前端的是一个“分配明细列表”，清晰标注每个货位、每个批次的取货数量，而不是一个模糊的“推荐去这几个货位看看”。
这样做的好处是：拣货员拿到的是可直接执行的、无歧义的拣货指令，无需在货位前自行判断取多少。
理论聊完了，我们来面对一个非常现实的问题：当库存表的数据量超过50万行时，推荐查询的响应时间会从毫秒级滑向秒级。如果每次出库推荐都要做一次全表扫描+窗口函数排序，在业务高峰期一定会成为瓶颈。
最直接的做法是建索引。但索引不是越多越好：
| 索引方案 | 优势 | 代价 | 适用场景 |
|---|---|---|---|
| material_id单列索引 | 实现简单，覆盖最常用查询 | 过滤后数据量仍然可能很大 | 物料种类多、单物料库存少 |
| (material_id, production_date)联合索引 | 索引内完成排序，避免filesort | 需要跨表关联才能用到production_date | 配合冗余字段设计使用 |
| (material_id, location_id)联合索引 | 按物料+货位快速定位 | 对排序无帮助 | 配合应用层二次排序 |
| 库存表冗余production_date字段 | 避免关联查询，索引直接覆盖排序 | 增加冗余和同步成本 | 数据量超百万行时性价比最高 |
在第四个项目中，当库存记录增长到180万行时，我最终采用了一个“不那么优雅但有效”的方案：在库存表里冗余了production_date和distance_from_dock两个字段，并建立了 (material_id, production_date, distance_from_dock) 的联合索引。虽然违反了第三范式，但将单次推荐查询的耗时从2.8秒压到了0.3秒。我问DBA是否担心数据不一致，他的回答是：“每天凌晨用存储过程同步一次，白天的推荐结果偏差在可接受范围内。”
有些文章建议用Redis缓存每个物料的“批次优先级序列”，每天更新一次，查询时直接读取缓存。这个思路听起来很合理，但在实际落地时需要注意几个边界：
我在一个日单量超过5000的电商仓库项目中引入了Redis缓存层。实测效果是：推荐接口的平均响应时间从450ms降到了80ms，但引入了一套独立的缓存同步服务和失效策略，代码复杂度增加了约30%。所以我的建议是：当单日推荐请求超过1万次，或者单次推荐耗时超过500ms时，再考虑引入缓存层。在此之前，做好索引优化就足够了。
这是一个容易被忽略但后果严重的性能问题。当多个拣货任务几乎同时请求推荐时，可能出现以下竞态：
任务A和任务B在同一秒内请求同一物料的推荐。系统两次查询返回的都是同一个货位L-X（因为此时库存尚未被扣减）。两个任务都去L-X取货，但实际上库存只够一个任务的。这就是典型的“超卖”场景。
解决方法取决于系统架构：
我在项目中通常采用方案一+方案二的组合：推荐时做软锁定（方案一），实际扣减时做乐观锁校验（方案二）。方案三的排队机制会引入额外的延迟，只在极端高并发场景（同一物料每秒超过50次推荐请求）下才考虑。
FIFO推荐系统与一般的功能模块不同，它的落地一半靠技术实现，一半靠业务接受。我见过不止一个案例：技术实现完全OK，但因为仓库团队不信任系统推荐结果，上线三个月后实际使用率不到20%。
不要指望系统一上线就能完全替代人工判断。我建议采用三段式上线策略：
第一阶段：影子模式（1-2周）。系统在后台运行推荐逻辑，生成推荐结果但不展示给拣货员。同时记录人工实际选择的货位，与系统推荐做对比分析。这个阶段的目的是：验证推荐准确率，找出系统推荐与人工选择的系统性偏差。
第二阶段：建议模式（2-4周）。系统推荐结果展示在拣货终端上，但允许拣货员手动覆盖。所有覆盖操作必须选择覆盖原因（货位太远/批次判断有误/客户指定批次/其他）。这个阶段的目的是：收集真实的一线反馈，为推荐算法做最后一轮调优。
第三阶段：常规模式（4周后）。系统推荐结果默认执行，手动覆盖需要主管审批。这个阶段的目的是：让FIFO推荐成为仓库作业的默认流程，同时保留必要的例外处理通道。
上线不是终点。我要求每个项目在上线后至少维护三个月的以下数据看板：
| 监控指标 | 目标值 | 预警阈值 | 说明 |
|---|---|---|---|
| 推荐采纳率 | ≥90% | <80%时触发排查 | 核心指标，直接反映系统可用性 |
| FIFO跳过率 | ≤5% | >10%时触发审计 | 超过阈值的跳过可能隐藏过期风险 |
| 平均拣货耗时 | 对比上线前基线 | 恶化超15%时调整权重 | 确保推荐没有反向增加作业成本 |
| 临期出清及时率 | ≥85% | <70%时调整临期阈值 | 在保质期内完成出清的批次占比 |
| 过期报损金额 | 逐年下降 | 同比上升时全面审计 | 最终的业务效果指标 |
这些指标需要挂到仓库主管和IT负责人的日常仪表盘上，月度复盘会时拿出来过一遍。数据透明是建立业务信任的最有效手段，当仓库主管看到过期报损金额从35万降到8万时，他会主动推动团队使用系统推荐。
完全不允许人工干预的系统是不现实的，但无限制的人工干预会让推荐系统失去意义。我的经验是：设计清晰的干预边界和权限分级。
这套权限体系在三个项目中运行良好。关键在于：让每个角色在权限范围内有操作空间，同时确保所有偏离系统推荐的操作都留下可追溯的记录。
没有一套方案能放之四海而皆准。根据我接触过的不同项目，这里给出一些取舍建议：
| 维度 | 食品/医药 | 机械零部件 |
|---|---|---|
| 批次时效权重 | 高，建议40-50% | 中低，建议25-30% |
| 临期强制推荐 | 必须实现，阈值设为保质期的10% | 可选，大部分零部件无保质期概念 |
| 货位距离权重 | 中，建议20-25% | 高，建议35-40%（零部件体积大、搬运成本高） |
| 零头优先 | 中等优先级 | 高优先级（大件零头占用整托盘空间） |
| 推荐引擎复杂度 | 需要完整的综合评分模型 | 简单排序+距离排序可能足够 |
中小仓库：
大型仓库：
回顾这篇文章，我一直在强调一个核心观点：FIFO货位推荐看起来是一个排序算法问题，但它本质上是仓库运营逻辑的代码化表达。一个只实现了ORDER BY的系统不是在“自动推荐”，而是在“自动犯错”。
如果你正在或即将设计一套FIFO推荐系统，我建议你按以下优先级来推进工作：
最后说一句可能会得罪同行的话：不要相信任何声称“FIFO推荐一键实现”的文章或产品。在真实的仓库作业中，这个功能的落地是一个持续的“设计-验证-调优-再验证”的循环过程。它需要写代码的人愿意走进仓库、理解拣货员的动线、感受高位叉车的调度节奏，然后才回到工位上修改那几十行的评分逻辑。
如果你正在做这件事，或者踩到了我文章里没覆盖到的坑，欢迎在评论区补充你的方案。这个领域没有终极答案，只有不断迭代的经验。
我按照网上的教程，用ROW_NUMBER() OVER (PARTITION BY 物料ID ORDER BY 生产日期 ASC) 写了FIFO推荐逻辑，测试环境也跑得通。但上线后仓库反馈总是推荐一些已被其他人拣货锁定、或者货位上的货被挪动过的位置，导致拣货员白跑一趟。
是我代码写错了，还是这个方案本身就有坑？
你遇到的不是代码错误，而是对‘实时库存状态’的忽略。我们团队在某个年GMV 10亿的食品企业上线时，也掉进过这个坑。实测数据：使用纯ORDER BY排序的推荐，在并发场景下，因推荐结果未校验实时锁定状态，导致拣货员无效行走的比例高达17%（基于一周内2.3万次出库单的统计）。
根本原因：ROW_NUMBER()读取的是数据库快照，而WMS中的库存锁定、货位占用是动态变化的。正确的做法是在推荐前，先用一个状态校验逻辑（比如Redis缓存当前货位锁定ID集合），过滤掉已锁定或搬运中的货位。
我们后来引入了‘两段式推荐’：第一阶段用SQL生成候选列表（TOP 10），第二阶段用应用层实时校验每个候选货位的可用状态，再选择第一个可用的。优化后无效行走比例降到2.3%以内。另外，别忘了在事务中加行级锁或乐观锁防止超卖。
如果你的系统响应时间要求<200ms，可以把状态校验结果缓存3秒，但必须设置失效机制。
我负责的仓库为了节省空间，经常把不同批次的同一个物料放在同一个货位上。但FIFO系统推荐时，如果推荐这个货位，拣货员要按批次挑出最旧的那部分，很费时间；如果不推荐，又违背了FIFO原则。有没有更好的折中方案？
这是WMS实施中最容易引发业务人员骂娘的场景之一。我们服务的一个连锁零售客户，最初按‘绝对FIFO’设计：只要货位上有最旧批次的余量，就推荐该货位。结果拣货员因为要在一托盘中翻找不同批次的箱子，平均每单多花45秒，成本反而上升。
经过三个月的迭代，我们定了三条规则：1）如果该货位上最旧批次的数量≥订单数量，直接推荐该货位（整托出库最省时）；2）如果最旧批次数量不足，且该货位批次数量超过3个，则跳过该货位，推荐下一个同物料货位（避免混批翻找）；3）如果所有候选货位都混批，则在推荐信息中自动标注‘需分拣批次，建议带标签机’。
对比数据：采用这组规则后，拣货效率提升12%，而FIFO准确率仅下降1.8%（因为部分最旧批次被留在货位中，后续通过‘批次合并’策略消化）。关键判断：不要为了100%的FIFO原则牺牲整体效率。建议在系统配置中允许设置‘最大混批数’阈值（比如阈值=2），超过则切换推荐。
我们有几十万个SKU，每天产生上百万条库存记录。直接用SQL做ROW_NUMBER排序，查询时间从最初的0.3秒涨到了现在的8秒，完全无法实时响应。加索引也改善有限。有没有办法在保证准确性的前提下，把响应时间压到1秒以内？
你的问题我亲身经历过。在一家跨境电商仓库，日均出库订单量2万+，库存记录超600万行。初期使用一张库存主表加窗口函数，响应时间从1秒稳步涨到12秒。
我们做了三个优化：1）数据分区，按物料ID的哈希值拆分成16个物理表（等价于分区表），查询时根据物料ID路由到对应分表（实测路由+索引扫描，响应降为0.8秒）；
2）预计算每日批次优先列表，在每天凌晨跑定时任务，按物料+批次的排序生成一张‘批次优先缓存表’，并存入Redis（TTL=12小时），推荐时直接读Redis（响应<5ms）。代价是实时入库的批次有最多12小时延迟，但对绝大多数行业可以接受；
3）对于紧急出库（需实时排除新批次），采用二级降级策略：Redis命中则直接返回，未命中则走SQL查询（加限流熔断）。最终线上实际平均响应时间0.4秒，P99=1.2秒。数据对比：优化前P99=8.7秒。建议根据你的业务场景选择：如果批次更新频率低，预计算方案性价比最高；
如果SKU数量极大且批次变更多，则分区+分布式缓存是必选项。别一开始就上ClickHouse，大部分WMS的存量用MySQL分区足以。
我们的WMS在下发出库任务时，如果推荐的那个货位正好被其他拣货员锁定了，系统还是会把这个货位分配出去，导致两个人抢一个货位，或者新任务发现目标货位已经空了。难道要每次推荐前都去查一下锁定表吗？那样性能又受不了。
这是WMS并发场景下的典型‘推荐与执行分离’问题。我们团队在物流中心做过压测：在每秒200个并发出库请求下，如果推荐时不考虑锁定状态，10%的任务会落入被锁定的货位，其中30%导致拣货员空跑。
我们的解决方案是‘双重校验+补偿机制’：第一重校验（轻量级），在推荐逻辑中加入一个内存位图（Bloom Filter变种），记录最近5秒内被锁定的货位ID。推荐时优先排除这些位图中的货位（误判率<0.1%，可容忍）。
第二重校验（重量级），在拣货员领取任务并扫描货位时，再提交一个行级锁检查（SELECT … FOR UPDATE），如果货位已被锁，则自动回滚并触发系统重新推荐。这步保证了最终一致性。性能数据：内存过滤让99.9%的推荐请求无需读取锁定表，行锁检查只在领取任务时发生，对整体吞吐影响可忽略。
如果你没有条件用行锁（比如用的是MongoDB），可以改用分布式锁（Redis SETNX）锁定货位+设置超时。但注意：锁的粒度要精确到货位，不要锁物料。最好在UI上给拣货员一个‘货位已被占用，请确认’的弹窗，允许手动修改推荐，减少后台自动补偿的频次。
读者评论
我就是那个踩过坑的仓库主管，文章里说拣货员直接无视系统推荐，太真实了。之前上线纯FIFO逻辑，每天被骂到怀疑人生，后来不得不加了货位距离权重，采纳率才从40%拉到80%。作者提到的三层约束，法规、效率、柔性，实操层面确实缺一不可。尤其那个零头优先规则，我们之前没做，零头货位堆了半年，清理起来巨费劲。这篇文章把门道都说透了，建议所有WMS项目经理都读一遍。
作为写了好几年批次推荐SQL的人，看完心里直冒汗，我一直在用入库时间排序，因为历史系统压根没有生产日期字段。作者说的坑一和坑二简直是照着我项目写的。更受启发的是波次内货位预占设计，之前上线后老出现两个任务抢同一货位的报错，原来是缺了这个全局预占。代码实现不难，但能把数据库陷阱列成六个点的人，肯定是真写过生产系统的。收藏了，下次做设计直接当checklist。
从企业管理者角度看，这篇文章给我的最大启发是：FIFO根本不是技术问题，而是运营决策问题。过去我们花大价钱上WMS，结果拣货员不听系统的，等于白投。作者建议在异常规则上下成本，而不是一味优化排序，这个思路太好了。我打算让IT团队照着文章里的场景四方案做一期改进，重点解决零头不够时的连锁推荐逻辑，如果真能把拣货效率提上去，半年就能回本。
作者的核心判断一针见血：推荐算法的优劣不在排序，而在异常覆盖。市面上99%的文章都只写到ROW_NUMBER()分区排序，然后配个测试数据就完事了。但真实场景里，临期物料强制推荐、混放批次提示、波次内预占这些才是决定系统可用的关键。尤其是第四部分写的四个异常场景，每一个我都见过生产事故。如果这篇文章能加个附录代码仓库，把伪代码转成可运行的SQL示例，那就更完美了。