AWS API Gateway集成DynamoDB响应码映射未生效 400错误返回200

你的配置一共存在三层逻辑错误，直接导致响应映射完全失效：

• 字段大小写错误，导致所有正则规则被忽略
  API Gateway 的 OpenAPI 扩展中，集成响应的正则匹配字段必须是全小写开头的 selectionPattern，你在配置中写的是首字母大写的 SelectionPattern，这类不符合规范的字段会被 API Gateway 直接丢弃，完全不参与解析。
  字段失效后，你定义的三个集成响应分支全部没有有效匹配规则，按照 API Gateway 的解析逻辑，会将第一个无匹配规则的分支（也就是你写的第一个 default 分支）作为唯一兜底规则生效，后面的400、500分支会被完全跳过——这也是为什么上游返回400时，客户端最终收到200的直接原因。
• 混淆了 default 兜底规则的定位
  API Gateway 明确要求default标记的集成响应必须是不携带任何匹配规则的兜底分支，仅用于所有带正则的规则全部匹配失败时的场景。你给本该是兜底的default分支加了无效的匹配字段，进一步加剧了解析逻辑的混乱。
• 正则匹配的对象理解偏差
  对于type: aws的非代理模式集成，selectionPattern默认匹配的内容根本不是上游返回的HTTP状态码数字：
  • 调用成功时，匹配的是上游返回的2xx状态描述文本（如200 OK）
  • 调用失败时，匹配的是上游返回错误体中的__type字段值（比如你日志里DynamoDB返回的com.amazon.coral.service#AccessDeniedException）
    就算你把字段大小写改对，写的4\\d{2}、5\\d{2}这类匹配数字的正则，在错误场景下也永远无法命中——因为错误场景的匹配文本里根本不存在以4、5开头的三位数字串。

• 把所有规则里的SelectionPattern改为小写开头的selectionPattern，保证字段能被正常解析
• 调整规则顺序与内容，让带正则的规则放在前面，无正则的兜底规则放在最后：
  • 成功响应分支：配置selectionPattern: "2.*"匹配所有2xx的成功场景，映射为200状态码
  • 客户端错误分支：配置selectionPattern: ".*AccessDeniedException|.*ValidationException|.*ResourceNotFoundException"，匹配常见的DynamoDB客户端类错误，映射为400状态码
  • 最终兜底分支：定义为不带任何匹配规则的default分支，用来捕获所有未被前面规则命中的场景，映射为500状态码
• 所有分支配置的CORS响应头保持和原配置一致即可，不需要额外调整。

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