如何从AWS DynamoDB的ConditionalCheckFailedException获取更多详情？

这个问题确实挺头疼的——DynamoDB不管是单条件还是多条件的条件检查失败，返回的异常信息都一模一样，根本没法直接知道哪个条件没通过。不过有几个方法能帮你精准定位问题，涵盖了生产可用和调试取巧的方案：

• 分步验证条件（最直接的兼容方案）
  你可以把复合条件拆成两次请求来验证：先调用GetItem接口，用ProjectionExpression只获取需要检查的属性（比如user_id和iq），然后在客户端自己判断这两个条件是否满足。如果user_id不存在，直接就能确定是第一个条件失败；如果存在但iq不等于85，就知道是第二个条件的问题。
  唯一需要注意的是并发风险——如果两次请求之间有其他操作修改了数据，结果可能有偏差。如果业务对一致性要求高，可以开启ConsistentRead: true来保证读取的是最新数据。

• 用事务拆分多条件检查（生产环境更可靠）
  DynamoDB的事务支持多个独立的ConditionCheck操作，你可以把原来的复合条件拆成两个单独的检查步骤：一个检查attribute_exists(user_id)，另一个检查iq = 85。当事务失败时，返回的TransactionCanceledException异常里会包含CancellationReasons数组，里面会明确指出哪个ConditionCheck操作失败了，甚至能给出具体的失败原因（比如“Attribute does not exist”或者“Attribute value does not match”）。
  举个简单的请求结构示例：

  {
    TransactItems: [
      {
        ConditionCheck: {
          TableName: 'your-table-name',
          Key: { user_id: { S: 'target-user-id' } },
          ConditionExpression: 'attribute_exists(user_id)'
        }
      },
      {
        ConditionCheck: {
          TableName: 'your-table-name',
          Key: { user_id: { S: 'target-user-id' } },
          ConditionExpression: 'iq = :targetIQ',
          ExpressionAttributeValues: { ':targetIQ': { N: '85' } }
        }
      },
      // 这里加入你的更新操作
      {
        Update: {
          TableName: 'your-table-name',
          Key: { user_id: { S: 'target-user-id' } },
          UpdateExpression: 'SET ...'
        }
      }
    ]
  }
  

  这样哪个条件不满足，就能从异常的CancellationReasons里直接找到对应操作的错误信息。

• 调试阶段的快速排查法
  如果只是开发调试时想快速定位问题，可以临时把复合条件拆成单个条件分别测试：先只保留attribute_exists(user_id)执行更新，如果成功，说明这个条件没问题，再换成只保留iq = 85测试；如果第一个条件就失败，那问题就出在user_id不存在上。这个方法简单粗暴，但不适合生产环境，毕竟需要修改代码重新部署。

内容的提问来源于stack exchange，提问作者aring