同一个Bearer Token有时正常、有时提示The consumer isn’t authorized。若请求在多节点间轮询，优先比较app/etc/env.php里的crypt/key和OAuth配置；节点密钥不一致时，加密数据无法互认。

复现与判断

我保留了一个失败样本，并用同样输入在无缓存或单节点条件下再跑一遍。这样可以把前端假象、缓存和真正的数据问题分开。

数据库和日志对照

  • 在负载均衡器临时固定到单节点复测。
  • 比较配置文件校验和，不要把密钥内容打印进聊天或工单。
sha256sum app/etc/env.php
bin/magento config:show oauth/access_token_lifetime/customer
curl -I https://shop.example.com/rest/V1/customers/me -H "Authorization: Bearer REDACTED"

为了避免把环境差异当成根因，我会先在预发布或数据库副本复现；涉及订单、库存和支付的操作，正式环境只做只读核对，修复脚本必须带明确的订单号或SKU范围。

这次的修法

从可信部署源把同一crypt/key安全分发到全部节点，权限设为部署用户可读，不进公开仓库。清理生成配置并滚动重启PHP-FPM。密钥曾漂移期间生成的Token应统一吊销或让用户重新登录；不要同时保留两套未知密钥尝试解密。

修改范围

  • 先在单个SKU、单个订单或单个Store验证。
  • 保留可回退的旧配置，不覆盖原始证据。
  • 需要批量处理时分批提交并输出成功/失败清单。

验证结果

  • 同一Token连续经过所有节点均成功
  • 新旧节点校验和一致
  • 滚动发布后Token不随机失效
  • 日志不再出现decrypt/authorization交替错误

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

顺手记下

更换crypt/key还会影响已加密配置值，操作前必须确认备份和影响范围。

如果线上数据已经不一致，先停掉会继续扩大差异的入口，再修历史数据；否则一边补一边写，最后很难判断哪些记录已经处理。