后台看到子商品 Quantity 大于 0，并不等于当前网站可售。启用 MSI 后，前台判断的是网站绑定 Stock 的 salable quantity；它由 Source 数量、Source 状态、预留量和阈值共同计算。父商品还要求至少一个启用、可见关系正确的子商品可售。

用具体子 SKU 查询可售量

php bin/magento inventory:reservation:list-inconsistencies -r

SELECT source_code, sku, quantity, status
FROM inventory_source_item WHERE sku IN ('CONF-A-RED','CONF-A-BLUE');
SELECT stock_id, website_id FROM inventory_stock_sales_channel;

确认当前网站对应 stock_id 后，再查该 stock 的索引表：

SELECT sku, quantity, is_salable
FROM inventory_stock_2
WHERE sku IN ('CONF-A-RED','CONF-A-BLUE');
SELECT sku, SUM(quantity) reservation_qty
FROM inventory_reservation
WHERE sku IN ('CONF-A-RED','CONF-A-BLUE') GROUP BY sku;

表名中的数字必须使用实际 stock_id。Source 有货但索引 is_salable=0，重点查 Source 是否分配到该 Stock、预留量和阈值。

核对父子关系和子商品资格

SELECT parent_id, product_id
FROM catalog_product_super_link
WHERE parent_id=(SELECT entity_id FROM catalog_product_entity WHERE sku='CONF-A');
SELECT entity_id, sku FROM catalog_product_entity WHERE sku LIKE 'CONF-A%';

后台逐个检查子商品 Enabled、网站分配和必选属性值。某个子商品缺少 super attribute 值时，即使有库存也不会成为可选组合。

索引与补偿

php bin/magento indexer:status inventory catalog_product_attribute
php bin/magento indexer:reindex inventory catalog_product_attribute
php bin/magento inventory:reservation:list-inconsistencies -r

若不一致命令给出补偿建议，先核对订单生命周期，再把输出通过官方 compensations 命令处理；不要手工删除 reservation。修复后分别测试访客、两个网站、最后一件库存下单与取消订单，确认父商品状态随子商品变化正确更新。

生产环境操作前的检查

针对“Magento 2 可配置商品有库存却显示缺货”进行处理时，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；需要 UPDATE、DELETE、补偿命令或目录删除时，必须先确认命中范围并保留可恢复备份。多 Web 节点环境还要比较代码版本、app/etc/env.php 摘要和当前流量节点，避免只修复其中一台。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。生产站不要同时运行多个全量索引或静态部署任务；若涉及数据库结构、库存、支付或订单，先在脱敏的生产数据副本验证，再安排维护窗口。

建立可比较的排查记录

每次实验只改变一个变量，并保存“操作前值、执行命令、开始时间、结束时间、结果、回滚方式”。至少准备一个正常对象和一个异常对象作对照，例如两个 SKU、两张订单或访客与登录客户。若修复后仅当前对象恢复，而新建对象仍会复现，说明根因尚未消除。

检查点需要记录通过标准
数据层 主键、Store/Website、更新时间、关联行数 关系完整且无孤儿记录
应用层 异常堆栈、模块、Cron/消费者状态 无新异常并可重复执行
缓存与索引 索引模式、版本、源站和公网响应 按预期周期自动更新
业务回归 正常路径、失败路径、重复请求 结果一致且没有重复副作用

修复后的观察窗口

上线后不要只刷新一次页面就结束。至少观察一轮 Cron、队列消费和索引周期，并在两台节点、无痕浏览器及目标 Store View 重复验证。对日志、数据库行数、错误率和响应时间设置临时观察项；确认它们稳定后再移除调试日志。调试日志可能包含客户、订单或令牌信息，采集时要脱敏，问题结束后及时关闭。