点击“加入购物车”后接口返回 No such entity with cartId = ...，很多人会先清缓存或重建索引。这个异常中的实体通常是 Quote，不是商品。Magento 2 对访客购物车使用 masked ID，对登录客户又会通过会话和 customer_id 找活动 Quote；只要前端保留了旧 ID、Quote 已失活或多节点 Session 不一致，就会出现“浏览器认为购物车存在，服务器却找不到”。

先确认报错来自哪一个端点

在 Network 中记录请求 URL、方法和返回体。/rest/V1/guest-carts/{cartId}/items 里的 cartId 应是 mask；/rest/V1/carts/mine/items 依赖登录 token；GraphQL 的 cart_id 同样通常使用 masked ID。不要把数字 quote_id 暴露给访客接口，也不要把 mask 当数据库主键查询。

从 mask 找到真实 Quote

SELECT qm.masked_id, qm.quote_id,
       q.is_active, q.customer_id, q.store_id, q.updated_at, q.items_count
FROM quote_id_mask AS qm
LEFT JOIN quote AS q ON q.entity_id = qm.quote_id
WHERE qm.masked_id = 'REQUEST_CART_ID';

没有 mask 行，说明 ID 可能来自另一个环境、数据库被清理，或前端缓存了旧值。mask 存在但 quote 不存在，是孤立关系；quote 存在但 is_active=0，可能已经转成订单或被购物车合并。不要把已下单 Quote 强行改回 active，这会制造重复下单风险。

登录切换时最容易失配

访客登录后，Magento 会尝试把访客 Quote 与客户现有活动 Quote 合并。自定义登录、单点登录或前端应用若仍继续使用登录前 mask，而后台已经关闭旧 Quote，下一次写入就会失败。成功登录后应以服务端返回的新购物车身份刷新客户端状态，清理 localStorage 中旧 cart_id，并重新加载 customer-data。

如果问题只在负载均衡后出现，检查 Session 是否共享、Cookie 域与 path 是否一致，以及 API 请求是否发送正确 cookie/token。轮询不同节点得到不同结果，通常不是 Quote 表随机丢数据。

过期清理与自定义 Cron

长期未更新的 Quote 会按配置清理。第三方“数据库优化”任务若按 created_at 而不是 updated_at 删除，可能误删活跃长周期购物车。对照异常时间、Quote 清理日志和数据库备份，确认是否有 DELETE。生产环境不要为避免报错无限保留所有 Quote，应修正清理条件和客户端过期处理。

修复标准

分别测试新访客建车、刷新页面、登录合并、退出后重新建车、完成订单后再次购物五条路径。每一步记录客户端 cart_id、mask 映射、真实 quote_id 与 is_active。接口遇到过期 cart 时应明确创建新车或提示刷新，而不是在后端猜测并复活旧 Quote。

对于移动端和 Headless 前端，还要测试应用被系统挂起数天后恢复、切换账号和多 Store View。客户端应给 cart_id 设业务有效期，收到明确的不存在响应时只重建一次，避免拦截器在循环重试中不断创建空购物车。