Slack斜杠命令迁移至Lambda后出现400_client_error排查求助

我来帮你梳理这个问题，之前我迁移Slack命令到Lambda时也遇到过类似的400报错，咱们一步步来定位原因：

1. 先查Lambda对Slack请求参数的处理逻辑 #

你用curl测试时没有携带Slack实际发送的请求参数，但Slack的POST请求会包含一堆必填字段：token、team_id、command、user_id等等。如果你的Lambda代码里直接尝试读取这些参数却没做容错处理（比如没判断参数是否存在），或者对token的验证逻辑出错（比如Signing Secret不匹配），就会抛出异常导致返回错误，而curl请求因为走了默认分支才返回正常。

建议你在Lambda代码里加详细日志，把接收到的event对象完整打印出来，然后触发一次Slack命令，去CloudWatch日志里看具体哪一步出了问题——比如是不是某个参数缺失导致KeyError，或者签名验证失败。

2. 必须实现Slack的请求签名验证 #

Slack现在强制要求所有斜杠命令请求必须验证签名，否则直接返回400错误。如果你在Heroku上没做这一步（可能当时还没强制要求），迁移到Lambda后必须补上：

• 从请求头获取X-Slack-Signature和X-Slack-Request-Timestamp
• 构造签名串：v0:{timestamp}:{原始请求体}
• 用你的Slack Signing Secret作为密钥，通过HMAC-SHA256加密签名串，再和请求头里的签名对比
• 如果验证失败，Lambda要返回403状态码，否则Slack会判定请求无效。

3. 确认API Gateway的集成配置和响应格式 #

如果你的API Gateway用的是Lambda Proxy集成，Lambda的响应必须符合特定格式，不能直接返回JSON对象：

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "text": "Have suggestions to improve this bot? Message <@UC8R7PA87>",
            "response_type": "in_channel"
        })
    }

如果直接返回JSON对象，API Gateway可能无法正确解析响应，导致给Slack返回400——虽然curl测试看似正常，但Slack的请求可能触发了不同的处理路径。

4. 查看CloudWatch和API Gateway日志 #

这是最直接的调试手段：

• 打开Lambda控制台，进入你的函数，在「监控」标签里打开CloudWatch日志，搜索Slack请求触发的日志条目，看是否有异常栈信息。
• 打开API Gateway控制台，启用访问日志（如果没开的话），配置到CloudWatch，查看Slack请求的详细日志：包括请求头、请求体、响应状态码和内容，确认API Gateway是否正确传递了请求，以及Lambda到底返回了什么。

5. 尝试调整响应中的转义字符 #

你的响应里用了<@UC8R7PA87>，虽然Heroku这么返回没问题，但Slack其实支持直接写<@UC8R7PA87>（不需要HTML转义），可以尝试去掉转义后再测试，这个可能性虽然低，但值得一试。

按照这些步骤排查，应该能快速定位到具体的错误原因。我之前就是漏了签名验证，加上Lambda响应格式不对，才导致Slack返回400的。

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