品牌 B 的订单生成了品牌 A 的发票前缀，或编号突然跳到另一序列。Magento 的订单、发票、Shipment 和 Credit Memo 分别按 Store 使用 sales_sequence 配置；自定义开票若加载错 Store 或手工设置 increment_id 会破坏它。

固定复现条件

记录订单 entity_id、store_id、发票 entity_id/increment_id 和创建入口。对比同 Store 的正常发票，并检查 sequence meta/profile 与实际 sequence 表。

SELECT entity_id,increment_id,store_id,created_at FROM sales_order WHERE entity_id=123;
SELECT entity_id,increment_id,store_id,order_id,created_at FROM sales_invoice WHERE order_id=123;
SELECT meta_id,entity_type,store_id,sequence_table FROM sales_sequence_meta ORDER BY entity_type,store_id;
SELECT profile_id,meta_id,prefix,suffix,start_value,step,warning_value,max_value FROM sales_sequence_profile ORDER BY meta_id;

根据证据定位

订单 store_id 错误会连带选择错误序列；自定义代码在 admin Store 创建发票可能丢上下文；多节点并发不应造成重复，但手工回调 sequence 值可能。编号间隙通常合法，不应等同于重复。

修复与回滚

通过标准 Invoice 服务基于订单创建，不手工设置 increment_id。修正 Store 上下文和 sequence 配置后，只对未来发票生效；历史编号涉及审计和财务要求，不应直接重编号。

验收

两个 Store 并发创建多张发票，各自前缀与唯一性正确；退款和 Shipment 序列不受影响，失败事务不会产生重复编号。

生产环境操作前的检查

处理“Magento 2 发票编号使用了错误店铺序列”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、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 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层证据通过标准
入口 URL、状态码、请求 ID、节点 路由与协议一致
应用 异常堆栈、模块、作用域 无新异常且可重复
数据 主键、时间、关联行数 关系完整无重复副作用
业务 正常、失败与重试路径 最终状态一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。