客户离上海仓很近，订单却总建议从广州仓发货。排查前要先澄清一个常见误区：Magento 下单时通常生成的是 Stock 级别 reservation，不是立刻从某个 Source 实物库存扣减；具体来源往往在创建 Shipment、执行 Source Selection 时才确定。
先确认订单属于哪个Stock
Website 会映射到 Stock，Stock 再包含多个 Source。网站如果挂错 Stock，后面的算法再聪明也只能在错误的仓库集合里选。后台逐层核对 Website → Stock → Source，并确认每个 Source 已启用、商品 Source Item 状态为 in stock。
Priority算法不会理解“离客户最近”
默认 Source Priority 按后台配置顺序扣减，它不知道地理距离。Distance Priority 才会结合地址与距离提供方，但还依赖完整的发货地址、国家地区代码、经纬度或距离服务配置。看到“选错仓”先确认当前使用的是哪个算法。
在创建发货页面记录系统给出的 source 和 qty 建议，然后对照各 Source 的可用数量。不要只查 inventory_source_item 的 quantity，reservation 会影响 salable quantity，而算法还可能考虑是否能完整满足发货。
bin/magento inventory:reservation:list-inconsistencies
bin/magento indexer:status inventory自定义算法要检查输入，而不只是排序代码
如果项目按省份、邮编或仓库成本自定义选择策略，先把订单地址、候选 Source、可用数量和排序分数写入结构化日志。地址字段为空、邮编格式不同或地区名称被翻译，都可能让算法走默认仓。
还要区分“推荐来源”和“实际发货来源”。管理员可以手动改 Source，ERP 也可能忽略 Magento 建议自行分仓。最终库存从哪扣，要看 Shipment 和 Source Deduction 执行记录，而不是只看下单页面。
如果订单已经发货却扣错仓，沿消息队列检查 source deduction message 使用的 source_code 和 sales_channel。异步消费者停掉时，后台可能已经生成 Shipment，但 Source Item 数量尚未更新；这时重复创建补偿脚本反而会二次扣减。先确认消息是否仍在队列、是否失败以及 reservation 是否已释放。
距离算法还要留意地址质量。国家、省份和邮编缺一项时，距离服务可能无法计算并回退到优先级。把算法返回的候选列表、距离和回退原因记下来，才能解释为什么某笔订单去了远仓，而不是凭地图肉眼判断。
修复后用同一 SKU 测试单仓可满足、需要拆仓、最近仓缺货和虚拟商品四种订单。只测试库存充足的一单，很容易把优先级调整误认为距离算法已经正常。
