Spring Boot调用AWS Lambda出现随机请求头缺失错误求助

核心成因 #

这个交替成功失败的问题，本质是Lambda容器复用导致的请求上下文污染：
Lambda冷启动后会复用已初始化的容器处理后续请求，如果你的Lambda代码或依赖的框架中存在全局/静态变量存储请求上下文（比如awsRequestId），或者框架没有在每次请求后正确清理上下文状态，就会出现这种情况——第一次请求容器初始化，上下文正常；第二次复用容器时，旧请求的上下文没有被替换，导致无法获取当前请求的lambda-runtime-aws-request-id响应头，触发报错。

除此之外，还有两个次要可能：

• 自定义Lambda运行时或Spring Cloud Function这类适配框架的旧版本存在上下文隔离漏洞；
• 响应处理逻辑依赖了非线程安全的对象，容器复用后状态混乱。

解决方法 #

1. 移除全局/静态变量的请求状态存储 #

检查Lambda代码里是否用全局、静态变量存过请求相关信息（比如requestId、上下文对象），把这些变量改成请求局部变量，或者每次请求处理完主动重置：

public String handleRequest(Map<String, Object> input, Context context) {
    // 每次请求实时从Context拿当前的requestId，别用静态变量缓存
    String currentRequestId = context.getAwsRequestId();
    // 业务逻辑处理...
    return buildSuccessResponse(currentRequestId, businessResult);
}

2. 升级或配置框架的上下文隔离 #

如果用了Spring Cloud Function适配Lambda，直接升级到最新版的spring-cloud-function-adapter-aws——旧版本确实存在上下文清理不彻底的问题。另外，确保持有请求状态的Bean用prototype作用域，避免单例Bean跨请求污染状态。

3. 检查自定义运行时的响应头逻辑 #

如果是自定义运行时，务必保证每次处理请求时，从当前请求的Lambda-Runtime-Aws-Request-Id请求头读取值，原样写入响应的lambda-runtime-aws-request-id头，处理完请求后立刻清空所有请求相关的状态，别留到下一次复用。

4. 临时禁用Feign重试验证 #

检查Feign Client的配置，有没有开重试机制。如果Lambda偶尔的异常触发了Feign重试，可能加剧容器复用的上下文问题。可以先禁用重试看看：

@FeignClient(name = "lambdaApiClient", configuration = FeignClientConfig.class)
public interface LambdaApiClient {
    // 接口定义...
}

class FeignClientConfig {
    @Bean
    public Retryer feignRetryer() {
        return Retryer.NEVER_RETRY;
    }
}

5. 显式清理请求上下文 #

在Lambda处理方法的finally块里，主动清理请求相关的状态，比如ThreadLocal或者自定义的全局状态：

public String handleRequest(Map<String, Object> input, Context context) {
    try {
        // 业务处理逻辑
        return processBusinessLogic(input, context);
    } finally {
        // 清空Spring请求上下文
        RequestContextHolder.resetRequestAttributes();
        // 清空自定义的全局状态容器
        GlobalRequestState.clear();
    }
}

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