Middy + Node.js Serverless AWS Lambda 如何用单个handler处理多API端点？

核心思路是在Lambda内部嵌入轻量路由逻辑做请求分发，按业务域聚合接口，完全适配你的项目需求，具体实现步骤如下：

1. 配置API Gateway路由绑定 #

先在API Gateway侧把同业务域的所有接口统一绑定到同一个Lambda实例，比如用户管理模块的三个接口可以批量配置：

• POST /users → 绑定到user-service Lambda
• PUT /users/{userId} → 绑定到user-service Lambda
• GET /users/{userId} → 绑定到user-service Lambda
  如果用Serverless Framework部署，可以在serverless.yml里批量配置路由规则，无需单个声明，大幅减少配置工作量

2. Lambda内部实现路由分发+Middy公共逻辑复用 #

直接通过Lambda入参event里的httpMethod和path字段匹配对应处理逻辑，公共逻辑通过Middy中间件全局挂载，所有同模块接口共用，不用重复开发：

const middy = require('@middy/core');
const httpJsonBodyParser = require('@middy/http-json-body-parser');
const httpErrorHandler = require('@middy/http-error-handler');
const httpCors = require('@middy/http-cors');

// 各接口独立业务逻辑
const createUser = async (event) => {
  const userData = event.body;
  // 新增用户业务逻辑
  return { statusCode: 201, body: JSON.stringify({ message: '用户创建成功' }) };
};

const updateUser = async (event) => {
  const userId = event.pathParameters.userId;
  const updateData = event.body;
  // 编辑用户业务逻辑
  return { statusCode: 200, body: JSON.stringify({ message: '用户更新成功' }) };
};

const getUser = async (event) => {
  const userId = event.pathParameters.userId;
  // 获取用户业务逻辑
  return { statusCode: 200, body: JSON.stringify({ userId, name: '测试用户' }) };
};

// 路由匹配主逻辑
const routeHandler = async (event) => {
  const { httpMethod, path } = event;
  if (httpMethod === 'POST' && path === '/users') return createUser(event);
  if (httpMethod === 'PUT' && path.startsWith('/users/')) return updateUser(event);
  if (httpMethod === 'GET' && path.startsWith('/users/')) return getUser(event);
  
  return { statusCode: 404, body: JSON.stringify({ message: '接口不存在' }) };
};

// Middy包装主入口，中间件全局复用
exports.handler = middy(routeHandler)
  .use(httpJsonBodyParser()) // 自动解析JSON请求体，所有接口共用
  .use(httpCors()) // 统一处理跨域逻辑，所有接口共用
  .use(httpErrorHandler()); // 统一错误处理，所有接口共用

3. 高接口量场景优化（可选） #

如果单个业务域下接口超过10个，可以把路由规则抽成配置表，后续新增接口只需要加配置和对应处理函数即可，无需修改路由判断逻辑：

// 路由配置表，新增接口直接加对应配置即可
const routeConfig = [
  { method: 'POST', path: '/users', handler: createUser },
  { method: 'PUT', path: '/users/:userId', handler: updateUser },
  { method: 'GET', path: '/users/:userId', handler: getUser }
];
// 可配合`path-to-regexp`类库实现更灵活的路径参数匹配，适配复杂路由规则

方案优势 #

• 公共逻辑100%复用：身份校验、参数解析、日志上报、限流熔断这类公共逻辑只需要开发一次，同模块所有接口共用，没有冗余代码
• 降低冷启动概率：同业务域的请求都打到同一个Lambda实例，调用频率更高，冷启动次数远低于单接口单Lambda的架构
• 项目结构更清晰：按业务域拆分Lambda而非按接口拆分，100多个接口只需要拆成十几个按业务域划分的Lambda即可，维护成本大幅降低

补充注意：如果某单个接口流量特别大，可以单独拆出来作为独立Lambda部署，避免影响同模块其他接口，调整成本极低

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