海仓笔记 · 2026年8月19日仓库里最常听到的两个词，一个是"库位满了没"，一个是"这个库位装得怎么样"。听着像一回事，其实是两码事。
不少仓管把这两个概念混着用，结果要么天天喊爆仓、要么明明还能塞却不敢上架，库存和空间一直对不上账。
库位容量利用率，说白了就是看一个库位"装得有多满"。它不是一个死数，而是跟着库存走的动态状态。
我们算它、盯它，不是为了追一个漂亮的数字，而是为了在吞吐、效率和安全之间找平衡
装太满，上架卡壳、通道堵、补货频繁，甚至货塞不进去；装太少，库位空着，房租水电平摊不下来。
这里先划一条线：本文只聊库位容量负荷（装得多满），不聊"库位有没有货"（占用率），也不聊整仓面积利用率。
占用率只回答"这个位置是不是空着"放一箱也算 100%。
容量利用率回答的是"还剩多少余量"一个库位最多放 50 箱，现在只放了 1 箱，利用率就是 2%。
管仓库的人该盯的是后者，因为它直接对应上架风险和承重安全。
一、算之前，先定"容量"的口径
容量不是只有一种算法。托盘货架、拆零货架、地堆、悬臂货架，约束条件都不一样。
如果统统按体积算，承重和箱数限制就被忽略了，算出来的数会失真。
常见要抠的几个维度：
- 可用体积：库位里真正能塞货的体积。
- 承重上限：货架层板或库位能扛的最大重量。
- 可放箱数：用库位长宽高分别除以料箱长宽高，取整相乘，再扣掉承重和层板限制。
- 可放托盘数：托盘货位常用，基本是整数。
- 可堆叠层数：地堆或货架的层数限制。
- 地面面积：地堆能占多大的地。
核心公式就一句：
库位容量利用率 = 已使用容量 ÷ 可用容量 × 100%
关键是分子和分母必须同一个口径。算体积利用率，就用"现有库存总体积 ÷ 库位可用体积"；
算重量利用率，就用"现有库存总重量 ÷ 承重上限"。
同一个库位往往同时卡着好几条线。
比如一个托盘位，体积才用了 60%，但货重已经快顶到横梁承重了，你要是按体积判断"安全"，仓库其实已经埋了隐患。
重货体积小但压秤，轻抛货体积爆满但没几斤。
所以得用多个维度交叉看，哪个维度最接近上限，就以那个维度为准，这才是真实的负荷。
按库位类型，大致这么分：
- 托盘货架库位：体积利用率和重量利用率都算，取高的值当综合负荷。
- 拆零拣选库位：优先看箱数或件数，因为拆零货物形状乱，体积算不准。
- 地堆库位：先看面积利用率，同时盯层数限制。
- 特殊库位（长料、悬臂等）：按长度或承重算，别硬套体积公式。
二、数据不准，算法再漂亮也是白搭
这个公式要跑起来，得先有三样底表：库位主数据、物料主数据、库存数据。缺了或错了，算出来的数连参考都不配。
库位主数据要有的字段：库位编号、类型（托盘/拆零/地堆/悬臂）、可用长宽高或可用体积、承重上限、可堆叠层数、所属库区。
物料主数据要有的：物料编码、单件体积和重量、单箱体积和重量、包装长宽高、单箱装箱数。
库存数据要有的：当前库位、件数、箱数、托盘数、库存状态（可用/冻结/待检）。
数据质量有四个坑，几乎每个仓都踩过：
1、包装尺寸和重量不能大量缺失。
缺了就只能填默认值。默认值偏大，系统以为还能塞，实际塞不进；
默认值偏小，又容易把承重风险算漏。最好按物料大类分别设默认值，隔段时间拿实测数据校准一遍。
2、单位必须统一。
库位用毫米、包装用厘米、体积一会儿升一会儿立方米，这种混搭最坑。
动手前先归一口：长度用米、重量用公斤、体积用立方米。
3、标称尺寸不等于可用尺寸。
标称是货架的几何尺寸，可用尺寸得扣掉横梁厚度、托盘高度、安全间距、消防喷淋、存取设备净空。
一个标称层高 1.2 米的货架，扣完可能只剩 0.9 米。按标称算，容量会被明显高估。
4、库存状态要过滤。
冻结、待检、待报废这些不能用的库存，算不算进利用率，得先定规矩。一般建议排除掉，免得干扰正常库位的判断。
三、四种算法，按场景挑着用
1、体积利用率 = 当前库存总体积 ÷ 库位可用体积。库存以件存就用"件数 × 单件体积"，以箱存就用"箱数 × 单箱体积"。适合形状规矩、包装数据齐整的整箱存放。
2、重量利用率 = 当前库存总重量 ÷ 库位承重上限。必须单独算，尤其是重货。很多仓储事故不是因为空间不够，是因为忘了承重。
3、箱数/件数利用率 = 已放箱数 ÷ 最大可放箱数。拆零库位用这招最准，能看出拣选面挤不挤。
4、面积利用率（地堆）= 已占地面面积 ÷ 可用地堆面积。地面没满但堆叠层数到顶了，照样得按综合值预警，不然就会出现"地上还有空位但堆不了高"的误判。
综合利用率不是把几个维度平均一下。
对同一库位，体积、重量、箱数都算完，取最接近上限的那个当综合值。
举个例子：体积 70%、重量 92%、箱数 80%，综合利用率就按 92% 算，并且立刻触发重量预警。
要是平均一下变 78%，看着挺稳，其实承重已经快爆了。取最大值，是为了让动作先对准最危险的那个约束。
四、预警阈值，别全仓一刀切
阈值得按库位类型、出货频率、补货节奏和消防要求分别定。
高频出库的拆零位，利用率到 85% 可能就影响拣货了；低频的重货托盘位，利用率可以更高，但重量线必须卡死。
大致分四档：
- 红色：利用率 ≥ 95%，或任一维度破上限。停上架、立刻移库或调整。
- 黄色：85%～95%。重点盯，优先移库或改补货策略。
- 正常：50%～85%。留着就行。
- 低效：低于 30%。库位占着资源却不干活，该合并库存、释放库位，或者换个更合适的存储策略。
这里单独强调一句：重量过载要当独立红线。哪怕体积利用率看着很低，只要重量接近上限，必须预警，不能因为综合值不高就装看不见。
阈值还得跟着业务波动走。比如大促前入库猛，可以把黄色线从 85% 降到 80%，提前留出余量。
调阈值主要看三件事：历史同期的峰值和均值、接下来一段时间的入库和促销计划、库位本身的作业特点。
五、预警不是发了就完事，得闭环
预警怎么算、怎么推，得说清楚，不然它就躺报表里没人管。
频率有两种：一种是库存一变动就重算（上架、移库、盘点后即时算），响应快但要系统支撑；
另一种是日终批处理，全仓扫一遍，适合日常管理。实际多半是两者结合，重点库位用实时，全仓用定时。
输出形式也得多管齐下：看板做热力图让主管一眼看到高负荷区；
把红黄预警直接变成任务推给上架员和库管；再按月度报表看趋势。
高负荷库位常见的应对：停上架、改上架规则别再分这个位、移到空闲位、把满载位拆成俩、降安全库存、对长期高负荷的物料重新划存储区。
低负荷库位：合并同种物料、释放空位、调整分配策略（小库位给小批量高周转货用）。
最关键的还是闭环。预警从产生、确认、指派、执行到复核关闭，少一环它就不是管理动作，只是通知。
系统里可以把状态分成"待确认 / 处理中 / 已关闭"，记上处理人和时间。
没闭环的预警别从看板消失，否则用久了大家就当它不存在了。
六、几个容易踩的坑
数据准比算法复杂重要。包装、库位、承重数据要是错的，模型再高级也算不出能用的数。上了系统先治理主数据，别急着堆功能。
别只看全仓平均值。整仓平均 60% 看着安全，某个高频拣选区可能已经 95% 了。要盯库区级、库位级的分布和变化趋势。
短期峰值不等于长期不够。大促连着几天冲到 90% 以上，活动一结束就回落。先看波动原因再决定要不要扩容，别被一时的高峰带着走。
分阶段推。别一上来铺所有库位类型。先搞托盘位（数据最规范），再扩拆零和地堆。指标上先做体积和重量预警，跑稳了再加低效预警。
阈值得业务和系统一起维护。定太低，预警刷屏，人麻了；定太高，问题藏住了。建议每季度或半年回看一次。
七、总结
如果你管的是多平台 + 多仓库，这件事会难十倍
上面这套逻辑，单个仓库手工盯还能凑合。可一旦你同时跑亚马逊、美客多、TikTok 欧洲站，仓库可能还分国内仓和海外仓，问题就变了：
- 库存散在好几个平台和好几个物理仓，到底哪边快爆了，哪边空着，靠人肉对表基本对不清；
- 调拨、移库一旦发生跨仓，A 仓腾出的容量和 B 仓新增的负荷，如果不同步，预警就失真，刚算完又得重来；
- 补货节奏卡在"数据不同步"上：明明总库存够，却因为某仓缺货被迫停上架，或者反过来重复补货堆爆另一个仓。
顶妙WMS解决的就是这个"多平台多仓一盘货"的麻烦。
它把各平台的库存攒成同一盘账，库存变动实时同步，库位级的上架、移库、补货调拨在系统里直接跑闭环，不用你在几个后台之间来回切。
上面讲的容量利用率、重量预警、低负荷合并这些策略，也能按仓库和库位类型分别配置，跨仓一起算。
说白了，库位利用率这套算法，的价值不在公式本身，而在它能每天帮你把"哪个库位该停、哪个该补"这件事自动说清楚。
仓库越大、平台越多，越该让系统替你把这块扛下来。
顶妙WMS
仓姐Tina
跨境简一
大麦victory
