更新
从写作开始，lambda已更新调用签名，现在传递事件，上下文，回调。

而不是调用 context.done（错误，res）你应该使用 callback（err，res）。请注意，context.done的情况仍然适用于回调模式。

Instead of calling context.done(err, res) you should use callback(err, res). Note that what was true for context.done still applies to the callback pattern.

还应该在API网关代理和集成实现中添加这一点，这整个线程已经过时了。
如果您要将API Gateway与Lambda集成，我建议您阅读本文： http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy- for-lambda.html

Should also add that with API Gateways proxy and integration implementation this entire thread is pretty much obsolete. I recommend reading this article if you are integrating API Gateway with Lambda: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-lambda.html

首先，让我们先澄清一些事情。

First things first, let's clear a few things up.

context。完成（错误，结果）; 只是 context.fail（错误）; 和 context.success的包装器（响应）;
Lambda文档明确指出如果错误为非null则忽略结果：

context.done(error, result); is nothing but a wrapper around context.fail(error); and context.success(response); The Lambda documentation clearly states that result is ignored if error is non null:

如果使用RequestResponse（同步）调用类型调用Lambda函数，则该方法返回响应正文，如下所示：
如果错误为null，则设置为e响应结果的字符串表示的主体。这类似于context.succeed（）。
如果错误不为null，则将响应正文设置为error。
如果使用类型为error的单个参数调用该函数，则将在回应机构。
http：// docs。 aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html

这是什么意味着无论你是使用失败/成功还是完成的组合都无关紧要，行为完全相同。

What this means is that it won't matter whether you use a combination of fail/success or done, the behaviour is exactly the same.

我已经测试了Lambda的每个可想到的响应处理组合以及API网关中的响应代码映射。

I have tested every thinkable combination of response handling from Lambda in combination with Response code mapping in API Gateway.

这些测试的结论是Lambda Error RegExp仅针对Lambda错误执行，即：您必须调用 context.done（错误）; 或 context.fail（错误）; 表示RegExp实际触发。

The conclusion of these tests are that the "Lambda Error RegExp" is only executed against a Lambda error, i.e: you have to call context.done(error);or context.fail(error); for the RegExp to actually trigger.

现在，这个呈现一个问题，已经注意到，Lambda接受你的错误并将其粘贴在一个对象中并调用 toString（）关于你提供的任何东西：

Now, this presents a problem as, has already been noted, Lambda takes your error and sticks it in an object and calls toString() on whatever you supplied:

{ errorMessage: yourError.toString() }

如果你提供了一个错误对象，你就会得到这个：

If you supplied an error object you'll get this:

{ errorMessage: "[object Object]" }

根本不是很有帮助。

到目前为止我找到的唯一解决方法是致电

The only workaround I have found thus far is to call

context.fail(JSON.stringify(error));

然后在我的客户端执行：

and then in my client do:

var errorObject = JSON.parse(error.errorMessage);

它不是很优雅但它有效。
作为我的错误的一部分，我有一个名为代码的属性。它看起来像这样：

It's not very elegant but it works. As part of my error I have a property called "code". It could look something like this:

{ 
    code: "BadRequest", 
    message: "Invalid argument: parameter name" 
}

当我对此对象进行字符串化时，我得到：

When I stringify this object I get:

"{\"code\":\"BadRequest\",\"message\":\"Invalid argument: parameter name\"}"

Lambda会将此字符串粘贴在errorMessage属性中响应，我现在可以安全地在API网关响应映射中找到。*BadRequest。* 。

Lambda will stick this string in the errorMessage property of the response and I can now safely grep for .*"BadRequest".* in the API Gateway response mapping.

这是一个非常黑的，可以解决两个奇怪的Lambda和API网关怪癖：

It's very much a hack that works around two somewhat strange quirks of Lambda and API Gateway:

1. 为什么Lambda坚持包装错误而不是只是按原样给b $ b吧？


2. 为什么API Gateway不允许我们在
   Lambda结果中grep，只有错误？

我正准备与亚马逊就这两个相当奇怪的行为开启一个支持案例。

I am on my way to open a support case with Amazon regarding these two rather odd behaviours.