很多装箱算法的教程默认只有一个箱子：给定一批货，求最大装载率。真实业务里更常见的是另一道题：一张订单 300 多个 SKU，要拆进两到四个柜子，每个柜子还要满足自己的限重、卸货站点和单证要求。单柜装得再漂亮，分配错了，后面全是返工。
一、先把问题拆成两层
第一层是分配：哪些货进哪个柜。第二层是装载：给定一个柜子的货，怎么摆。把两层揉在一起直接搜索，状态空间会爆炸；完全分开又容易出现「分配阶段看着能装，装载阶段装不进」。工程上常用的折中，是在分配层用便宜的下界和上界做筛选，在装载层用构造式启发式快速验证，不可行就回到分配层调整。
二、分配层要看的不只是体积
体积和重量是两个最直观的维度，但还要加上三类「硬分组」约束：同一 PO 是否必须同柜（单证要求）、同一卸货站点是否尽量集中、危险品或异味货是否必须隔离。建议把这些先写成分组规则，再做数值优化。否则算法会为了多塞一点体积，把两个站点的货切碎到三个柜里，目的港拆柜成本反而上升。
三、一个够用的迭代框架
① 按硬分组生成候选组；② 用体积与重量做一维装箱，得到最少柜数的下界；③ 对每个柜跑一次快速构造（底左优先或极点法），记录装不下的剩余件；④ 剩余件优先回流到同站点、余量最大的柜；⑤ 连续两轮没有改进就停止，输出方案与未装清单。这个框架不保证全局最优，但每一步都能解释，仓库和货代能看懂为什么这么分。
四、目标函数别只写一个
常见的写法是最小化柜数，再在柜数相同的情况下最大化最满柜的装载率。实际还应该加两个惩罚项：站点被拆分的次数、单柜重量偏离均衡的程度。前者影响目的港作业，后者影响陆运限重和整体配重。权重不需要一开始就调得很精，先让业务方看到不同权重下的两三个方案，再根据反馈收敛。
五、测试数据怎么造
只用随机立方体测，很难暴露分配层的问题。建议准备几组典型夹具：一个大站点加若干零散站点、重货集中在少数 SKU、同 PO 体积刚好超过一柜。每次改代码都跑这组夹具，看柜数、拆分次数和未装件有没有变坏。回归比单次跑分更能说明算法是否靠谱。
最后补一句：多柜问题里，「最后一个柜装多少」常常是商务问题而不是算法问题。尾柜只装一半时，是加货、拼箱还是改期，需要提前把选项交给业务，而不是让算法硬凑。
如果想看业界把多柜分配与装载预览放在同一流程里的做法，可以参考箱策云这类工具做方法对照；具体选型仍以自家数据与部署要求为准。文中参数为示意。
