Magento 2 MSI多源库存运营实战：source、stock、reservation与预留治理

保哥踩过4家Magento客户同一个坑：启用MSI之后，Salable Quantity跟quantity长期偏离5%-30%，所有人第一反应都是查库存数据；可真正的元凶是reservation预留表里的幽灵记录在悄悄吃可售量。多源库存不是开关问题，是把销售渠道、订单状态、索引器、reservation清理串成一条SOP的运营工程。

Magento 2.3起把MSI（Multi Source Inventory）写进了内核，把原来cataloginventory_stock单表的库存模型彻底拆成了source、stock、reservation三张关系表。这次重构不是给后台多加一个仓库下拉框那么简单，它把库存、订单、销售渠道之间的耦合关系全重画了一遍。可惜大多数运营团队迁过去的时候，只看见admin后台多了一栏Sources，就以为开个新源、把库存填进去就完事——结果三个月后OOS（缺货）闪烁、purchase order卡在pending、salable quantity长期跟quantity偏离，根因往往跟想的完全不一样。这篇文章是保哥在Magento Enterprise B2B、跨境DTC美妆、3PL仓配代运营三类客户里反复迭代的MSI运营SOP，从概念区分到迁移分步到reservation治理一路打通，能少踩8个坑。

Magento 2 MSI跟1.x单库存到底差在哪里？

Magento 1.x与2.0-2.2时代的库存逻辑非常直接：每个SKU在cataloginventory_stock_item里只有一行，is_in_stock、qty、min_qty三个字段把“还能不能卖”这件事讲完了。仓库这个概念在系统里是不存在的，发货由人工或第三方扩展决定。这种模型在单仓单店时代够用，但一旦碰到三种场景，立刻塌房：

• 跨境DTC同时跑美仓和欧仓，欧洲消费者下单要从离自己最近的仓库扣减——单库存模型完全做不到分仓扣减。
• 同一批商品既在自营独立站卖，又通过Marketplace（亚马逊、eBay）分销，渠道库存隔离做不出，超卖与漏卖二选一。
• B2B跟B2C共享同一池库存，B2B要预留安全库存只对大客户开放，B2C看到的可售量得自动减掉这部分预留——单字段根本表达不了这种条件可见性。

MSI把上面这三种刚需拆成了三个相互正交的概念：source是物理或法律意义上的仓库实体，stock是把多个source组合成一个销售视图，sales channel把stock跟具体website挂钩。任何一个SKU在每个source上各有一份quantity，最终消费者看到的salable quantity是stock视图下所有source的可用量减去reservation之后的动态值。换句话说，MSI把“库存有多少”和“现在能卖多少”做了一次彻底解耦，这是它强大的地方，也是它复杂的地方。

对独立站运营而言，这个差异最直接的影响在两件事上。第一件，仓库数据现在是一等公民，所有报表、API、订单流都得按source维度重新组织，不再是SKU级别的一行流水账。第二件，可售量变成了“实时计算结果”而不是“存储字段”，这意味着reservation表只要出问题，前台显示就立刻偏离真实库存，问题排查从查一行数据变成查一段计算链路。Adobe Commerce库存管理文档把MSI的整体架构图画得很清楚，建议团队迁移前先全员读一遍，少80% 概念混淆。

source、stock、salable quantity、reservation这四个名词怎么分？

这四个词是MSI里最容易被混用的概念，混在一起讲会让运营和开发对不上账。新员工onboarding的第一节课，我都先把这四个词的边界画清楚。

Source（源）对应一个真实仓库或履约实体，每个source有自己的source_code、地址、是否启用、优先级。一个SKU在每个source里有独立的quantity行，存在inventory_source_item表里。Source是物理世界的镜像：你有几个仓，系统里就应该有几个source。哪怕是dropshipping模式，每个供应商也应该建一个source，方便后期分账与库存预警。

Stock（库存视图）是把多个source组合成一个可销售单位的抽象层。Default Stock是系统初始就有的一个，把所有source汇总；你可以新建US Stock只挂美仓source、EU Stock只挂欧仓source。Stock跟source是多对多关系，写在inventory_source_stock_link表里。每个stock在inventory_stock_X表里物化一份reservation后的可售视图，X就是stock_id。

Salable Quantity（可售量）不是字段而是一个动态计算结果：每个stock视图下，所有挂上来的source的quantity总和，再减去这个stock上所有pending、processing、未发货订单的reservation。它在产品列表页和详情页直接决定add to cart按钮是不是灰色，是消费者唯一感知得到的数字。

Reservation（预留）是MSI最关键也最容易出问题的概念。每当一个订单进入pending状态，系统会往inventory_reservation表写一行负值记录，表示这些数量已经被锁定但还没真正出仓；订单shipment完成或cancel之后，系统再写一行对应的正值记录把reservation平掉。Salable quantity就是source quantity减去这张表里相关SKU的累计reservation值。这套机制让系统避免了直接改quantity字段，从而摆脱了高并发下的锁竞争；代价是reservation表必须保持平衡，一旦失衡，前台显示就偏离真实库存。

把这四个词理清楚之后再看任何MSI报错或异常都会清晰很多——不需要先猜哪里出错，只要确认是source quantity漂了、stock关联坏了、salable计算异常还是reservation失衡，问题域就缩到了四分之一。

从Default Source迁到多源仓库要分哪6步？

新装的Magento 2.4默认已经启MSI，但绝大多数客户是从2.3之前或者刚装好用默认设置撑了一段时间才回头迁多仓，这种增量迁移比一次开局就规划好难得多。这套6步SOP是踩过两个数据回滚事故之后才定下来的，每一步都不能跳：

第一步，先在测试库克隆生产环境的catalog与inventory数据，跑bin/magento module:status确认Inventory* 模块全部启用。MSI由十几个子模块组成（InventoryApi、InventorySalesApi、InventoryConfiguration等），任何一个被禁掉都会导致后续source创建报黑屏。

第二步，新建source。在Stores → Inventory → Sources里给每个仓建一条，source_code用us-warehouse、eu-warehouse这种全小写带连字符格式，因为source_code写入URL与API路径之后改不掉。同时设置经纬度——这是distance priority算法的依据，没填的话source selection跑出来的结果全是按建立顺序而不是按距离。

第三步，新建stock并关联source。在Stores → Inventory → Stocks里建US Stock、EU Stock，每个stock勾选要挂的source。Default Stock千万别删——它是Magento的兜底，任何没被任何stock显式关联的source都会自动归到Default Stock，删掉之后SKU会突然消失。

第四步，把stock跟sales channel（也就是website）挂钩。这一步在stock编辑页底部，勾选要绑定的website即可。要点是一个website同一时间只能挂一个stock，所以multi-store架构下如果想让us-store、eu-store、b2b-store各自独立库存，需要先在系统配置里把multi-website拆出来。

第五步，把现存的SKU数量从Default Source拆到各个新source上。这一步最容易翻车——Magento不会自动按stock比例分配，必须用inventory_source_item表的批量更新脚本，或者通过REST API的inventorySourceItems POST接口逐条覆盖。一种保险做法是先把所有SKU在Default Source的quantity留0，把数量全部分到新source上，确认无误后再把Default Source从所有stock中unlink（但仍保留source本体，避免历史订单的reservation找不到归属）。

第六步，跑bin/magento indexer:reindex inventory，并定时cron每小时跑一次inventory_stock索引器。MSI的salable quantity不是实时计算的（那样性能上扛不住），而是依赖索引器把reservation与source quantity物化到inventory_stock_X表里。索引器没跑或者cron没配，前台显示就是上一次索引的快照，可能跟真实情况差好几小时。Magento 2升级2.3到2.4.7的12步SOP里也提到过，索引器与cron是Magento运维的两根命脉，MSI把这件事重要性又抬升了一个数量级。

Stock跟Website / Sales Channel该怎么挂？

很多团队在第四步卡住，因为他们不确定应该是一个stock对一个website、一个stock对多个website，还是反过来。这件事没有标准答案，要看商业模式。这里总结过4种典型搭配，可以直接对号入座：

第一种，单站多语言但单一发货区域。比如一个独立站只对北美卖，但站内做了英语与西班牙语两个store view。这种情况一个US Stock挂一个us-website就够了，多语言store view是website之下的概念，不影响库存视图。

第二种，多区域独立站完全分隔库存。北美用us.brand.com、欧洲用eu.brand.com，各自的stock与source完全独立。这种是MSI最舒服的用法——一个stock对一个website，库存隔离与发货归属同步完成。要注意的是，一旦同一个SKU在两个stock都需要，记得在source quantity上做物理分配而不是逻辑共享，否则两边都“看见”同一份量，一边卖空另一边还显示有货。

第三种，B2C与B2B共享物理仓但隔离销售。常见做法是同一个us-warehouse source挂到两个stock上：B2C Stock关联b2c-website，B2B Stock关联b2b-website。但这种共享有个隐患：B2C把库存卖光之后B2B仍会看到可售量，因为stock的salable是按各自reservation单独算的。解决方案是借助inventory reservation的negative threshold配置，把B2C Stock设为不允许低于0，B2B Stock留5% 安全缓冲，让两边的可售量在抢到一定阈值时自然停下。

第四种，多渠道分销（独立站＋亚马逊＋eBay）。这种不推荐直接用MSI自带逻辑，因为Marketplace的库存同步频率与时差跟MSI的索引器节奏对不上。比较稳的做法是用Channel Manager类插件做中间层，把Marketplace渠道当成一个virtual source挂到独立stock，由插件负责同步与回写。直接把亚马逊当sales channel关联到MSI stock的，三个月内必出超卖事故。

挂法定下来之后，记住一条原则：stock跟website的关联是单向覆盖式的，每次改这个映射Magento都会重建inventory_stock_X表，期间几分钟内前台salable全0。建议放在凌晨低峰跑，并临时把产品页改成backorder允许避免买家被吓走。

Source Selection Algorithm三种内置策略怎么选？

SSA（Source Selection Algorithm）决定一个订单进来之后系统按什么逻辑把SKU从哪些source扣减。Magento内置三种：Default Priority、Distance Priority、自定义算法。Adobe Commerce开发者文档把每种算法的接口写得很完整，但内置三种谁该用、谁不该用，文档讲得不深。

Default Priority按source上priority字段从小到大排序，订单SKU全量从优先级最高的source扣减，扣不完才往下一个source顺移。适合source只有2-3个、且业务上明确有“主仓”概念的场景。比如美国客户主要从加州仓发，纽约仓只是溢出备份，priority设10与90就行。

Distance Priority根据收货地址与每个source的经纬度算距离，从最近的扣减。适合source ≥ 3且地理分布广的场景，能把履约成本与时效一起优化。但要注意：distance priority不考虑source上的库存深度，如果最近的仓只剩1件、订单要5件，系统会从最近仓扣1件、再从次近仓扣4件，订单被拆成两个shipment——拆包成本比距离省的运费更高。建议给source加一个最小完成度阈值（自定义算法实现），低于这个数就跳过。

自定义算法实现SourceSelectionInterface即可。给一家家居DTC写过一版“距离＋库存深度＋仓库人效”三因子加权算法：先按距离过滤前3个仓，再按当前SKU库存深度排序，最后引入仓库当天picking人力（从WMS API拉取）做平衡。上线之后单订单履约成本下降13%，仓库爆仓投诉降到迁移前的三分之一。这种算法不复杂，难的是定期回看效果——每月固定看一次SSA跑出来的source分布，看有没有某个仓被过度依赖。

选好算法之后在Stores → Configuration → Catalog → Inventory → Distance Provider Configuration里指定算法实例。Distance Provider默认是Google Maps API，免费额度每月28000次调用，超过会断；客户里有人换成Mapbox或者自建OSRM服务器，按source数量算ROI，超过20个source就值得自建。

为什么Salable Quantity跟实际quantity长期偏离？

这是MSI启用后最高频也最让运营崩溃的问题。客户反馈“前台显示有8件可售，仓库WMS里查12件”或者反过来“前台只剩3件其实仓库还有30件”，第一反应都是查source quantity数据是不是错了，结果数据完全对，只是salable算出来偏。处理过的7起类似事故里有6起根因是同一个：reservation表残留。

Reservation之所以会失衡，主要有三种触发条件。第一种，订单cancel之后cron没跑或者跑失败，本来应该写一行正值平掉pending时那行负值的，没写——这条SKU的salable永远多扣了一份。第二种，订单从pending走到shipment complete的过程中，inventory_reservation_cleanup没把记录归档清理，老reservation跟新reservation叠加堆积，表越来越大，几个月后inventory_stock_X索引重建跑得极慢甚至超时。第三种，开发或外部脚本直接写过cataloginventory_stock_item改qty字段（这是Magento 1思维），跳过了reservation流程，前台salable完全不知道这次改动，跟新quantity错位。

排查这件事的标准流程：先跑bin/magento inventory:reservation:list-inconsistencies，这条命令会把source quantity与reservation加总跟inventory_stock表里物化的salable比对，把所有偏差的SKU列出来。如果列表里全是正常订单留下的reservation，那就是cron没跑；如果列表里有大量已经发完货的订单仍然有reservation记录，就是cleanup没执行；如果列表里出现某些SKU的source quantity跟salable完全对不上、reservation表里却找不到对应订单，那是被外部脚本绕过流程改qty了。

每种根因的修复手段不同：cron没跑，重启cron服务＋手动跑inventory_stock indexer一遍即可；cleanup没跑，bin/magento inventory:reservation:cleanup配合 --bypass-state-validation强清；外部脚本污染，需要排查所有直接写库存表的代码路径，改用InventoryApi的SourceItemsSave接口。

reservation残留怎么排查与一键清理？

知道有偏离之后下一步是治。Magento 2.4起官方在bin/magento里内置了三条专门治reservation的命令，但很多团队只知道第一条：

bin/magento inventory:reservation:list-inconsistencies列出所有source quantity与salable偏差的SKU。这条是诊断命令，不会改任何数据，可以放心跑。输出包含SKU、stock_id、quantity、salable_quantity、推断的inconsistency_qty。

bin/magento inventory:reservation:create-compensations是补偿命令。它会读取上一步发现的偏差，自动往inventory_reservation表写补偿记录把偏差归零。这条命令带一个 --raw参数可以直接生成SQL而不执行，建议先用 --raw输出审计一遍，确认补偿方向是对的（少扣的补减、多扣的补加）再正式执行。

bin/magento inventory:reservation:cleanup是清理命令。它会把所有已经完成订单（shipment complete或cancel）但reservation仍未平掉的记录归档清除。这条命令带 --bypass-state-validation参数允许跳过订单状态校验，给那些订单状态被外部系统强改过的场景兜底。

清理SOP是每天凌晨3点跑一次list-inconsistencies把结果发邮件给运营组，每周日凌晨跑一次create-compensations与cleanup把当周偏差与陈旧reservation一次性清掉。这套SOP在一家月单量4万的家居DTC客户跑了半年，期间没出现过一次salable漂移投诉。

如果业务量级很大、reservation表已经膨胀到几百万行级别，建议先用SQL直接对inventory_reservation表做归档：把stock_id、sku维度上累计reservation = 0的行批量删除，剩下的非平衡行让上述命令处理。这种SQL归档脚本客户跑过一次，5分钟从880万行降到4万行，inventory_stock索引重建从90分钟降到6分钟。DTC海外仓SKU周转率管理实战里那套ABC×XYZ分级方法跟reservation治理是配套的——高周转A类SKU优先保salable准确，C类长尾可以宽容点。

B2B / Marketplace多渠道库存该共享还是隔离？

这是MSI老板层面最常问的问题：要不要让B2B与B2C共用一个库存池？答案是分场景。这里用三个维度做决策：货值毛利、订单频度、断货容忍度。

货值毛利差异大的，建议隔离。B2B单笔5000美金、毛利30%；B2C单笔80美金、毛利65%。这种情况共享库存意味着B2C把货卖光之后B2B的大单接不下来，损失的不是单价乘以数量而是潜在年度合同。给B2B单独切一个stock同时挂同一个source上的“配额”（用source quantity的子集逻辑实现，或借助reservation的negative threshold），可以做到物理共享、可售隔离。

订单频度差异大的，建议局部隔离。B2C一天200单，B2B一周5单。共享库存的话B2B难得来一单经常发现“刚才查还有50件、现在下单只剩10件了”——B2C把库存抢走了。给B2B留10%-15% 的预留缓冲，每天cron自动把仓库当天到货的20% 优先补给B2B配额，运营起来B2B销售就不用每天问“今天还能签合同吗”。

断货容忍度低的渠道（比如亚马逊FBA Storefront），建议物理隔离。亚马逊一旦因为缺货导致buy box丢掉，恢复周期是7-14天的运营成本，比B2C临时OOS几小时严重得多。亚马逊渠道库存直接挂一个独立source（amazon-fba-warehouse），不在任何stock里跟其他源混挂，避免SSA把订单路由错。

多渠道分销SSA路由如果出错，连带Magento的Order Management（OMS）模块也会失准。DTC海外仓配4模式选型里讲过3PL/4PL混合架构的库存如何在系统层面切分，MSI是这套架构在Magento平台上落地的具体实现。

MSI性能与升级有哪些必须避开的坑？

MSI在小数据量下基本没性能问题，但source ≥ 5与SKU数 ≥ 30000之后开始显著影响整站性能。这里整理了8个性能与升级坑，按出现频度从高到低排：

• 第一个，inventory_source_item表EAV化之后单查询变慢。Magento 2.4起source item是关系表加attribute表混合存储，每次quantity更新都涉及多表JOIN。优化做法是给source_code、sku字段加复合索引，并把不常变的source_code用Redis缓存住。
• 第二个，inventory_stock索引器在SKU量大时长时间锁表。默认schedule模式实际是update on save，10万SKU量级一次全量重建要30分钟。建议改成stockUpdateIdle模式分批处理，或者用Async Operations把索引拆成消息队列消费。
• 第三个，MSI的GraphQL查询不返回salable_qty而只返回quantity字段。前端拿这个字段判断“能不能加购”会判错。需要在前端层重新调一次inventoryShipSourceSelection或者productSalableQuantityList接口拿到真实可售量。
• 第四个，2.3升级到2.4时inventory_reservation表的schema改了，原metadata字段从JSON字符串变成结构化JSON类型。Migration Script跑得慢且占大量IO，必须放在维护窗口。
• 第五个，MSI与第三方PIM/ERP集成时，ERP推库存常用cataloginventory_stock_item.qty字段（Magento 1 API残留），跳过reservation流程。这种集成必须强制改成InventoryApi/SourceItemsSave接口，否则salable永远跟ERP错位。
• 第六个，varnish缓存的页面会把过期的salable_qty缓存住，前台显示比真实多。需要在product cache tag里加上stock_id，stock更新时连带invalidate相关产品页缓存。
• 第七个，多语言store view切换时MSI不会自动切stock视图——这是因为stock跟website绑定而不是跟store view绑定。一个website下两个store view看到的是同一份salable，不会因为语言不同而变。
• 第八个，MSI启用后admin后台保存产品速度慢30%-50%，因为每次save都要写多个inventory_source_item行。建议在admin端用batch save模式或者通过API批量更新。

Magento Layered Navigation治理里讲过EAV与URL Rewrite表跟MSI性能问题的耦合：catalog_product_index_eav与inventory_stock索引器如果不分开调度，会互相抢占MySQL连接池。生产环境建议两个索引器错开时间跑，inventory_stock放凌晨2点、eav放凌晨4点，避开高峰。Adobe Commerce Release Notes每个版本都会更新MSI的性能修复清单，每次升级前过一遍能预防大量已知坑。

三个真实客户的迁移复盘有哪些可复用的教训？

下面三个客户案例都做过匿名化处理，但具体踩坑与修复方法是真实的，按“原状—踩坑—修复—复盘”四段拆出来，避免说成纯成功故事。

第一个，北美户外品牌，年营收1200万美金，5个仓（美西、美东、加拿大、英国、德国），SKU数1.8万。原状是Magento 2.3.5单库存，所有订单从加州仓发，邮费成本占毛利9%。迁移目标是按SSA distance priority自动分仓。踩坑：迁移第3周开始出现salable quantity跟实际仓库差15%-25%，运营每天处理30多个客户投诉。排查5天发现根因——客户的3PL系统通过老API直写cataloginventory_stock_item.qty跳过reservation流程，导致salable跟实际数据完全错位。修复路径是3PL同事改用InventoryApi接口推库存，并在Magento侧关闭老API的写入权限。复盘出来的教训是：MSI迁移不能只在Magento侧做，必须把上下游所有写库存的系统全切换到新API，否则reservation流程必被绕过。这个客户迁完之后邮费成本降到毛利的5.8%，单笔毛利提升1.5个百分点。

第二个，跨境美妆DTC，年营收600万美金，3个仓（美国3PL、欧洲FBA、东南亚自营），SKU数800。这家客户走的是B2C与亚马逊渠道分销混合模式，最痛的是亚马逊端经常因为MSI同步延迟出现overselling。原状是把亚马逊FBA库存放到独立source、挂到default stock上跟独立站共享。踩坑：FBA库存推送给亚马逊有6-12小时延迟，独立站这边实时扣减，结果同一份库存被双渠道重复卖了4单，亚马逊出于政策给账号警告。修复路径是把亚马逊渠道完全隔离——独立source、独立stock、独立website；亚马逊库存推送通过Channel Manager插件做中间缓冲。复盘出来的教训是：渠道隔离比共享更适合用MSI表达，多渠道共享只在前面B2B那种“高毛利低频度”场景才合算。

第三个，欧洲B2B工业品商城，年营收2300万欧元，1个物理仓但4个销售渠道（DTC、B2B大客户、经销商、内部员工自购）。原状是Magento Open Source 2.4.2，所有渠道共享default stock，B2B大客户偶尔下大单经常踢空小客户库存。踩坑：迁移到多stock隔离模式之后admin后台产品保存变慢60%，运营投诉强烈。排查2天发现是inventory_source_item表EAV化导致每次保存写12行attribute，复合索引缺失。修复路径是给inventory_source_item加 (source_code, sku) 复合索引，并把不常变的source元数据Redis缓存住。复盘出来的教训是：MSI多stock架构在SKU量级中等（万级）的时候性能问题暴露不出来，到三万级以上必须提前做索引与缓存优化，事后补救会影响日常运营节奏。

MSI迁移前一周该走哪份Checklist？

把上面所有踩坑提炼成一份迁移前一周的清单，团队拿着挨条对就能少70% 事故概率：

• 测试环境做source / stock / sales channel关系图，跟商业模式对照一遍，确保没有“漏挂的website”或“重复挂的source”。
• 所有写库存的上下游系统（ERP、PIM、3PL、Marketplace中间件）列出来，确认它们用InventoryApi而不是老cataloginventory API。
• cron服务跑过cron:status验证健康，inventory_stock索引器配indexer:set-mode schedule。
• varnish缓存tag配置加上stock_id维度。
• Distance Provider如果选Google Maps API，提前估算调用量与计费上限。
• SSA算法选定后写一个回归测试集（一批历史订单跑一遍看分仓结果是否合理）。
• reservation治理SOP写进运维wiki，每日list-inconsistencies、每周cleanup排期。
• admin后台PIM字段保存时长跑过基准（Save Product应在2秒内）。
• 开维护窗口跑首次全量indexer:reindex inventory，期间产品页临时切到backorder。
• 迁移后第1周每天人工对账：随机抽20个SKU比对admin salable与WMS实库。

这份清单保哥拿出来给客户走过5次，没一次走完之后reservation失衡或者超卖事故出现的。Adobe官方Commerce用户指南有一份英文版的MSI设置checklist，保哥这份是把英文版按中文外贸团队的运营节奏重写的，两份互补使用最稳；多渠道插件与自定义SSA算法可以直接去Adobe Commerce Marketplace挑现成的，避免自研重轮子。

常见问题解答

问：MSI启用之后能不能再切回单库存模型？

答：理论上可以，把Inventory系列模块disable之后会回退到cataloginventory_stock_item单库存模式，但reservation表里的历史数据不会自动清理，回退之后那部分订单的库存归属会丢失。不建议回退——既然走到MSI，应该是把现状治理好而不是退回老路。

问：可不可以让一个SKU在多个source里不显示库存数量，只显示“有货/缺货”状态？

答：可以。在Stores → Configuration → Catalog → Inventory → Stock Options里把Display Out of Stock Products与Stock Status拆开配置，前台仅显示状态而隐藏数量。这种做法对避免竞争对手扒库存数据有意义，但要注意add to cart时仍按实际salable走，库存少时下单可能直接报错。

问：MSI的reservation表会无限增长吗？

答：会，如果不定期清理。Magento内置inventory:reservation:cleanup命令把已完成订单的reservation归档，但不会自动定时执行。建议加cron每周日凌晨跑一次，单次清理量大时分批跑避免锁表。

问：跨多个store view但同一website的产品库存会自动按语言切吗？

答：不会。MSI stock跟website绑定，跟store view无关。同一个website下不同语言的store view看到的是完全相同的salable quantity，只是显示语言不同。

问：Custom SSA算法实现需要哪些接口？

答：实现Magento\InventorySourceSelectionApi\Api\SourceSelectionInterface接口的execute方法，输入是InventoryRequestInterface（包含stock_id与items），输出是SourceSelectionResultInterface（包含source列表与各自分配量）。然后在di.xml把自定义实现注册成新的algorithm code，admin后台Distance Provider Configuration就能选到。

问：MSI性能优化里source数量上限是多少？

答：没有硬上限，但实测source超过15个之后SSA distance priority算法明显变慢，全量indexer耗时显著增加。超过15个source的客户建议拆multi-website让每个website只管3-5个source，把SSA的计算范围收窄。

权威参考资料