Middy.js HTTP-CORS 中间件中的跨域响应头缓存问题分析

在Node.js服务端开发中，Middy.js作为AWS Lambda的中间件框架，其HTTP-CORS组件用于处理跨域资源共享(CORS)相关功能。本文将深入分析一个在特定场景下出现的CORS响应头缓存问题，帮助开发者理解问题本质并提供解决方案。

问题现象

当使用Middy.js的http-cors中间件时，在Lambda函数中如果以外部常量形式定义响应头对象，会出现跨域响应头缓存问题。具体表现为：

1. 首次请求返回正确的Access-Control-Allow-Origin头
2. 后续请求无论Origin如何变化，都返回首次请求的Origin值
3. Vary头会不断追加"Origin"值

例如配置允许两个源：

• http://localhost:3000
• https://example.org

当首次请求来自localhost时，后续所有请求（包括来自example.org的）都会返回localhost的源。

问题根源

经过深入分析，问题源于JavaScript对象引用和中间件处理逻辑的交互：

1. 对象引用问题：当响应头对象在handler外部定义时，该对象会在Lambda执行环境中被复用
2. 中间件行为：http-cors中间件会检查并修改响应头对象
3. 缓存效应：首次执行后，修改后的头信息会保留在对象中，影响后续请求

关键问题代码位于http-cors中间件的modifyHeaders函数，该函数直接修改了传入的headers对象而非创建副本。

技术细节

在Lambda执行环境中，外部定义的变量会在热启动时被保留。当响应头对象定义在handler外部时：

1. 首次执行时中间件添加Access-Control-Allow-Origin头
2. 该修改被保留在对象中
3. 后续执行时中间件检测到头已存在，不再更新

同时，Vary头由于每次都追加新值，会出现"Origin, Origin, Origin"这样的重复。

解决方案

开发者可采用以下任一方案：

1. 内联定义响应头：在handler函数内部直接定义headers对象

return {
  statusCode: 200,
  headers: { "Content-Type": "application/json" }
}

2. 每次创建新对象：即使使用外部常量，也通过展开运算符创建副本

return {
  statusCode: 200,
  headers: { ...CONTENT_TYPE_JSON_HEADER }
}

3. 更新中间件版本：Middy.js已修复此问题，更新到最新版本可从根本上解决

最佳实践

为避免类似问题，建议：

1. 避免在handler外部定义可能被中间件修改的对象
2. 对于需要复用的配置，使用不可变数据或每次创建副本
3. 定期更新中间件依赖，获取最新修复
4. 在测试中覆盖多次请求场景，验证CORS行为

理解这一问题有助于开发者更好地使用Middy.js中间件，并掌握Lambda执行环境中的对象生命周期管理。