异步批量接口很快返回一个 bulk_uuid，但几小时后查询状态仍是 open，商品一个也没更新。HTTP 202 只表示请求已被接收并拆成异步操作，不表示后台 consumer 已执行成功。
从 bulk_uuid 找到每一条 operation
先保存提交时间、调用身份、路由和返回 UUID。通过官方状态接口查看总数、成功、失败和未完成数量。若只有少数 operation 失败，先读单条错误；若全部未开始，重点查消息是否发布与对应 consumer。
数据库只读查询可用于辅助，但不同版本表结构可能变化，不要根据网上 SQL 直接改状态。状态表是结果，不是队列本身；把 open 手工改成 complete 不会执行任何业务。
确认负责拆分和执行的 consumer 都在运行
php bin/magento queue:consumers:list
php bin/magento queue:consumers:start async.operations.all --max-messages=1000实际 consumer 名称以当前版本列表为准。检查进程管理器、cron consumers_runner、RabbitMQ 队列深度和未确认消息。队列不断增长但 consumer 无进程，是运行问题；consumer 存在却吞吐为零，查连接、权限和处理异常。
一条毒消息可能拖住整个观察
输入数据的 SKU、website、属性类型或必填字段错误，会让 operation 失败。错误处理若不断 requeue，同一条消息可能被快速重复。为消息设置可控重试和失败落点，保留错误原因，不能无限热循环。
批量请求也要控制大小。一次塞几万条虽然减少 HTTP 次数，却会放大序列化、队列和失败重跑成本。按可观测批次提交，每批保存 UUID，做到失败批次可单独重跑。
重跑之前先判断操作是否幂等
更新商品属性通常可以按最终值重试；扣库存、创建客户或触发外部同步则可能有副作用。根据 operation 的业务键检查是否已经部分成功，不能看到 bulk 仍 open 就整体再次提交。
验收时故意加入一条错误数据：正常项完成，错误项给出明确失败，bulk 最终状态可解释；consumer 重启后未完成项继续处理，不产生重复副作用。这样异步链路才真正可运维。
