1. 这不是“不用服务器”，而是把服务器藏得更深——AWS Lambda 的真实面目

很多人第一次看到“Serverless”这个词，下意识觉得是“连服务器都不用了”，甚至有人以为这是某种魔法，代码扔上去就自动跑起来，连操作系统都不用管。我刚接触 AWS Lambda 时也这么想，直到在生产环境里连续三天凌晨三点被告警电话叫醒，才发现自己错得离谱：Serverless 不是消灭服务器，而是把服务器的运维责任从你肩上硬生生卸下来，再塞进 AWS 的黑盒里——而这个黑盒，只在你调用它时才真正启动，用完即焚。它的核心关键词从来不是“无服务器”，而是“按毫秒计费的、事件驱动的、完全托管的函数计算服务”。你写的不是应用，是一段被触发才执行的逻辑快照；你部署的不是服务，是一个等待 HTTP 请求、S3 文件上传、DynamoDB 数据变更或 CloudWatch 定时器敲门的“待命状态”。

这个项目标题“What Is Serverless AWS Lambda and How to Use It”，表面看是个入门科普，但背后藏着三类人的真实需求：第一类是刚从传统 Web 开发转云原生的工程师，卡在“为什么我的 Express 应用不能直接丢进 Lambda”；第二类是 DevOps 同事，正被老板逼着“砍掉闲置 EC2 实例”，却不敢动核心定时任务；第三类是初创公司技术负责人，在 MVP 阶段纠结“要不要现在就搭 Kubernetes”。Lambda 对他们而言，不是技术选型，而是成本结构和交付节奏的重写。它能做什么？一句话：把任何可拆解为“输入→处理→输出”的原子操作，变成无需预置容量、自动伸缩、按实际执行时间付费的独立单元。比如用户注册后自动发欢迎邮件、图片上传后自动生成缩略图、IoT 设备每分钟上报数据后实时写入数据库并触发异常告警——这些场景里，99% 的时间你的代码根本没在运行，但传统架构仍要为这 1% 的峰值时刻持续付费。Lambda 就是专治这种“时间浪费税”的。

适合谁来读这篇？如果你正在评估是否用 Lambda 替换某个 Python 脚本、Node.js 定时任务或 Java 微服务中的边缘功能；如果你已经写了第一个 Lambda 函数但搞不清为什么冷启动慢、超时失败、日志查不到；或者你只是想弄明白“为什么别人说 Lambda 便宜，我一上线账单反而涨了”——那这篇就是为你写的。它不讲抽象概念，只讲我踩过的坑、压测过的参数、上线前必须确认的 checklist，以及那些 AWS 官方文档里不会明说但决定你项目成败的细节。

2. 为什么非得是 Lambda？——架构决策背后的四重现实权衡

2.1 传统架构的隐性成本有多痛？

先看一个真实案例：我们曾维护一个电商后台的“订单履约状态同步”服务。它每 5 分钟轮询一次 ERP 系统，拉取新订单，再调用物流 API 更新运单号，最后写回数据库。用 EC2 部署，配了 2 台 t3.medium（4GB 内存，2 核），常年 CPU 利用率 8%，但每月固定支出 $67.2。问题不在钱——在于每次 ERP 接口变更，都要手动登录服务器改代码、重启进程、验证日志；每逢大促，得提前两天扩容，活动结束再缩容，稍有不慎就导致订单延迟同步。更糟的是，某次 ERP 系统临时维护 4 小时，我们的轮询脚本疯狂重试，触发了对方的限流机制，整个履约链路瘫痪。传统架构的痛点从来不是技术不行，而是“资源与负载永远不同步”——你为峰值买容量，却为低谷付租金；你为稳定性做冗余，却为变更付运维债。

2.2 Lambda 如何切中要害？四个不可替代的硬核优势

Lambda 的价值不是凭空来的，它精准击中了上述痛点的四个关键维度：

第一，毫秒级弹性伸缩，彻底告别容量预估。
传统服务扩容要算 QPS、预估并发、预留实例、配置 Auto Scaling 组……而 Lambda 的伸缩是“无感”的。当 100 个用户同时上传头像，系统会瞬间启动 100 个函数实例并行处理；流量退去，实例在几秒内自动销毁。它的伸缩单位不是“台服务器”，而是“单个函数执行上下文”。这意味着你不再需要为“可能发生的峰值”提前付费，而是只为“实际发生的执行”买单。实测数据：一个 256MB 内存、平均执行 800ms 的 Node.js 函数，处理 100 万次请求，费用约 $1.27（按 us-east-1 区域定价），而同等负载下 EC2 方案最低也要 $35/月（t3.micro 持续运行）。

第二，真正的按需付费，消灭闲置成本。
Lambda 计费模型只有两个维度：执行时间（精确到毫秒）和内存分配（以 MB 为单位）。没有“开机即收费”，没有“空闲连接保活费”。比如一个处理 S3 图片上传事件的函数，平均每次执行 320ms，分配 512MB 内存，那么每百万次调用成本 = (320ms × 512MB ÷ 1024) × $0.0000166667 ≈ $0.027。注意：这个公式里的“内存”不是你代码实际使用的量，而是你分配给函数的上限值——它直接影响执行速度和费用。我见过团队把内存从 128MB 直接拉到 3008MB，结果执行时间从 1200ms 降到 280ms，总费用反而下降 35%，因为时间节省的收益远超内存溢价。这背后是 AWS 的底层调度策略：更高内存意味着更多 CPU 配额（CPU 与内存线性绑定），所以“调高内存”常是比“优化代码”更高效的降本手段。

第三，全托管运维，释放工程师生产力。
你不需要关心 OS 补丁、安全组规则、磁盘 I/O 优化、JVM GC 调优。AWS 负责所有底层设施：从物理服务器、网络设备、虚拟化层，到运行时环境（Node.js/Python/Java/.NET 等）、监控日志集成（CloudWatch Logs）、密钥管理（Secrets Manager/KMS 集成）。你唯一要做的，就是写好 handler 函数，定义好触发器，然后点击“Deploy”。我们有个内部工具，原本由一位 SRE 全职维护，迁移到 Lambda 后，他腾出 70% 时间去重构核心交易系统。这不是偷懒，而是把人力从“救火”转向“防火”。

第四，事件驱动原生支持，天然适配现代云架构。
Lambda 不是孤立存在的，它是 AWS 事件总线（EventBridge）的天然消费者。S3 对象创建、DynamoDB 流变更、Kinesis 数据到达、API Gateway HTTP 请求、SQS 消息入队、CloudWatch Events 定时触发……所有这些事件源，都能零配置对接 Lambda。这意味着你可以用极轻量的方式构建松耦合系统：前端上传图片 → S3 触发 Lambda A 生成缩略图 → Lambda A 完成后发消息到 SQS → Lambda B 消费消息更新 CDN 缓存。整个链路没有中间件、没有消息队列运维、没有服务发现，全是 AWS 托管的事件管道。这种“事件编织”能力，是任何传统服务器架构都难以低成本复现的。

2.3 但它绝非万能药——三个必须清醒的认知边界

然而，过度神化 Lambda 是项目失败的开端。我亲手推翻过两个“Lambda 全栈”方案，原因很实在：

第一，长时任务根本不适合。
Lambda 单次执行最长只能 15 分钟（2023 年已从 5 分钟提升至此，但仍是硬限制）。如果你的任务涉及视频转码、大规模数据 ETL、机器学习模型训练，它天生就不在适用范围内。强行拆分会导致状态管理复杂度飙升（需用 DynamoDB 或 Step Functions 持久化中间状态），反而增加故障点。这类任务，ECS Fargate 或 EC2 Spot Instances 是更务实的选择。

第二，有状态应用无法直接迁移。
Lambda 实例是无状态的，且生命周期极短。你不能指望在函数里缓存数据库连接池（虽然可以，但连接数受限且冷启动时失效），也不能依赖本地磁盘存储临时文件（/tmp 目录虽有 512MB 空间，但仅限单次执行）。所有状态必须外置：数据库用 RDS/Aurora，缓存用 ElastiCache，文件存 S3，会话用 DynamoDB。这意味着，一个依赖 Session 的传统 Web 应用，绝不能简单把 controller 方法塞进 Lambda——你得先把它拆成无状态的 API 端点，再用 API Gateway 做路由和鉴权。

第三，冷启动延迟对用户体验敏感场景是硬伤。
当函数长时间未被调用，AWS 会回收其执行环境。下次调用时，需重新加载运行时、初始化代码、建立数据库连接——这个过程叫“冷启动”，通常耗时 100ms~1500ms 不等。对于后台异步任务（如发邮件、写日志），这无所谓；但对于面向用户的 API（如搜索建议、实时聊天），1 秒以上的延迟会让用户直接关闭页面。解决方案有二：一是用 Provisioned Concurrency（预置并发）让指定数量的实例常驻内存，代价是按小时付费；二是用 Application Load Balancer + ECS 作为兜底，只将非敏感路径交给 Lambda。我们最终在核心下单接口保留了 ECS，而将“地址解析”“优惠券校验”等子任务交给 Lambda，平衡了性能与成本。

3. 从零写出第一个可用的 Lambda 函数——手把手拆解每个环节

3.1 环境准备：避开新手最常踩的三个“权限坑”

别急着写代码，先搞定权限。Lambda 的权限模型是“执行角色（Execution Role）+ 资源策略（Resource-based Policy）”双保险，新手常在这里卡住。

第一步：创建执行角色（IAM Role）
这个角色决定了 Lambda 函数能访问哪些 AWS 资源。在 IAM 控制台创建新角色，选择“AWS service” → “Lambda” → “Next”。附加两个基础策略：

• AWSLambdaBasicExecutionRole：允许写 CloudWatch Logs（必须，否则看不到日志）；
• AmazonS3ReadOnlyAccess（如果函数要读 S3）或AmazonDynamoDBFullAccess（如果要操作 DB）——但强烈建议遵循最小权限原则，用自定义策略代替全权限策略。

提示：我见过太多人因忘记附加AWSLambdaBasicExecutionRole，导致函数执行后日志一片空白，排查两小时才发现是权限问题。CloudWatch Logs 组名默认为/aws/lambda/{function-name}，权限缺失时连这个组都不会自动创建。

第二步：配置信任策略（Trust Policy）
确保角色的信任关系允许lambda.amazonaws.com代入。标准模板如下：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

漏掉这一条，函数根本无法启动。

第三步：设置 VPC 访问（仅当需要访问私有资源时）
如果函数要连 RDS 或内部微服务，必须配置 VPC。但这会引入冷启动延迟（VPC ENI 创建需额外 1~2 秒），且需为子网分配足够 IP 地址。关键经验：除非绝对必要，否则不要把 Lambda 放进 VPC。大多数场景下，用 RDS Proxy 或将数据库设为 Publicly Accessible（配合安全组白名单）更轻量。

3.2 代码编写：以 Node.js 为例，写一个真正能用的 HTTP API

我们以“用户注册后发送欢迎邮件”为场景，用 Node.js 18.x 运行时实现。核心是理解 Lambda 的 handler 结构：

// index.js exports.handler = async (event, context) => { // 1. 解析事件：API Gateway 传入的 event 是标准化格式 const body = JSON.parse(event.body || '{}'); const email = body.email; // 2. 输入校验（永远不要信任外部输入） if (!email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) { return { statusCode: 400, headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ error: 'Invalid email format' }) }; } // 3. 业务逻辑：调用 SES 发送邮件（此处简化，实际需配置 SES） try { // 模拟异步调用（真实场景用 aws-sdk v3） await new Promise(resolve => setTimeout(resolve, 200)); // 4. 返回响应（API Gateway 要求严格格式） return { statusCode: 200, headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' // 启用 CORS }, body: JSON.stringify({ message: `Welcome email sent to ${email}`, timestamp: new Date().toISOString() }) }; } catch (error) { console.error('Email send failed:', error); // 自动记录到 CloudWatch return { statusCode: 500, body: JSON.stringify({ error: 'Internal server error' }) }; } };

关键细节解析：

• event参数是触发源传递的数据。API Gateway 传入的是包含httpMethod、pathParameters、body等字段的 JSON；S3 事件则包含Records[0].s3.bucket.name和Records[0].s3.object.key。永远先打印console.log(JSON.stringify(event, null, 2))查看结构，别猜。
• context对象提供getRemainingTimeInMillis()（判断是否快超时）、invokedFunctionArn（当前函数 ARN）等元信息，调试时很有用。
• async/await是必须的。Lambda 会等待 Promise resolve/reject 后才结束执行。若用回调（callback），必须显式调用callback(null, response)，否则函数会超时。
• 返回格式必须严格匹配 API Gateway 要求：statusCode、headers、body（字符串，需 JSON.stringify）。漏掉headers中的Content-Type，前端收到的就是乱码。

3.3 部署与测试：用 SAM CLI 本地模拟，比控制台快 10 倍

别在 AWS 控制台里手动上传 ZIP 包——那是 2015 年的做法。现在用 AWS SAM（Serverless Application Model）CLI，本地开发、测试、部署一体化。

安装与初始化：

# 安装 SAM CLI（需先装 Docker，因本地模拟需容器） pip install aws-sam-cli # 初始化项目（选择 Node.js 18.x 模板） sam init --runtime nodejs18.x --name welcome-email-lambda # 进入项目目录，修改 template.yaml cd welcome-email-lambda

关键配置template.yaml：

AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: WelcomeEmailFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello-world/ # 代码所在目录 Handler: index.handler # 入口函数 Runtime: nodejs18.x Timeout: 30 # 最大执行时间（秒），别设太小 MemorySize: 512 # 内存（MB），根据负载调优 Environment: Variables: SES_REGION: !Ref AWS::Region # 环境变量，避免硬编码 Policies: - AWSLambdaBasicExecutionRole - AmazonSESFullAccess # 仅示例，生产环境用最小权限策略 Events: ApiEvent: Type: Api Properties: Path: /register Method: post

本地测试全流程：

# 1. 构建（下载依赖、打包） sam build # 2. 本地启动 API（自动映射 http://localhost:3000/register） sam local start-api # 3. 在另一个终端测试 curl -X POST http://localhost:3000/register \ -H "Content-Type: application/json" \ -d '{"email":"test@example.com"}' # 4. 查看实时日志（Ctrl+C 停止） sam logs -n WelcomeEmailFunction --stack-name welcome-email-lambda

为什么 SAM 比控制台强？

• 本地模拟完全复现云端环境（包括权限、环境变量、事件结构）；
• sam local invoke可直接传入 JSON 事件文件测试 S3/DynamoDB 触发；
• sam deploy一键部署到任意区域，版本管理、别名切换全自动；
• 所有配置即代码（IaC），团队协作、CI/CD 无缝衔接。

3.4 关键参数调优：内存、超时、并发，如何用最少的钱跑最快的函数

Lambda 的性能与成本，90% 取决于这三个参数的组合。它们不是独立的，而是强耦合的。

内存（MemorySize）：最被低估的性能杠杆
AWS 将内存与 CPU 配额线性绑定：1792MB 内存 ≈ 1 个 vCPU。这意味着：

• 分配 1024MB，CPU 配额约为 0.57 个 vCPU；
• 分配 3008MB（最大值），CPU 配额 ≈ 1.68 个 vCPU。

实测对比（Node.js 18.x，处理 1MB JSON 解析+加密）：

结论：从 128MB 提到 512MB，时间降了 62%，费用反降 34%；再提到 1024MB，时间再降一半，费用持平；提到 3008MB，时间只快 32%，费用却涨 35%。最优性价比点往往在 512MB~1024MB 区间。我的建议：先用 512MB 基准测试，再按 256MB 步进向上调，直到执行时间收益小于费用增幅。

超时（Timeout）：安全阀，不是摆设
默认 3 秒太短，容易误杀正常请求。设置原则：

• 同步调用（如 API Gateway）：设为预期最大耗时的 1.5 倍（如平均 800ms，设 1200ms）；
• 异步调用（如 S3 事件）：可设到 15 分钟，但需在代码里主动检查context.getRemainingTimeInMillis()，避免超时中断导致数据不一致。

注意：超时会触发Task timed out错误，且不计入重试（异步调用除外）。若函数依赖外部 API，务必加AbortController设置请求超时，否则 Lambda 可能卡死到自身超时。

并发（Concurrency）：控制洪水的闸门
Lambda 默认有账户级并发限制（1000），但可申请提高。更精细的控制是：

• 预留并发（Provisioned Concurrency）：为函数预热指定数量的实例，消除冷启动。适合流量可预测的 API（如每日 9:00 上班打卡接口）。费用 = 预留数量 × 每小时单价 × 730 小时/月。
• 预留并发 + 预置并发（Provisioned + On-Demand）：预留 10 个实例保底，超出部分走按需并发。这是成本与性能的黄金平衡点。
• 预留并发 + 预置并发 + 预留并发（Provisioned + On-Demand + Reserved）：别这么干，复杂度爆炸。

4. 生产级落地必做的七件事——从能用到稳用的跨越

4.1 日志与监控：别让 CloudWatch 成为你的盲区

Lambda 自动生成日志到 CloudWatch Logs，但默认配置极易让你抓瞎。

必须做的三件事：

1. 启用 X-Ray 追踪：在函数配置中开启 Active Tracing。X-Ray 会自动捕获函数执行时间、子调用（如 DynamoDB 查询、S3 下载）、错误堆栈，并生成可视化调用链。没有它，你无法定位“为什么这个 API 平均延迟 2 秒”——是函数本身慢？还是下游 RDS 查询慢？还是网络抖动？

2. 结构化日志，别用console.log：console.log('User created:', user.id)生成的是纯文本，搜索困难。改用 JSON 格式：

console.info(JSON.stringify({ level: 'INFO', event: 'user_registered', userId: user.id, timestamp: new Date().toISOString() }));

再配合 CloudWatch Logs Insights 查询：

filter @message like /user_registered/ | stats count(*) as total, avg(@duration) as avgDuration by bin(1h) | sort avgDuration desc

3. 设置日志保留期：默认永久保留，但 CloudWatch Logs 按 GB/天收费。生产环境建议设为 90 天（RetentionInDays: 90in SAM template），既满足审计要求，又控成本。

4.2 错误处理与重试：Lambda 不是永动机，得教它“知难而退”

Lambda 的重试机制分两类，必须明确区分：

同步调用（如 API Gateway）：

• 默认不重试。函数抛出异常或超时，API Gateway 直接返回 502/504。
• 你必须在代码里处理所有可能错误：网络超时、下游服务不可用、JSON 解析失败……并返回合适的 HTTP 状态码。

异步调用（如 S3 事件、SQS 消息）：

• 默认重试 2 次（共 3 次执行），间隔指数退避（100ms → 200ms → 400ms）。
• 若三次都失败，消息进入 DLQ（Dead Letter Queue）。DLQ 是生命线，必须配置！

  Resources: MyFunction: Type: AWS::Serverless::Function Properties: DeadLetterQueue: Type: SQS # 或 SNS TargetArn: !GetAtt MyDLQ.Arn

实操心得：我们曾因未配 DLQ，导致 S3 图片上传失败后消息无限重试，最终压垮下游服务。后来强制规定：所有异步 Lambda 必须配 DLQ，且 DLQ 消息需自动触发告警（SNS → Slack）。现在，失败消息 5 分钟内就能被人工介入。

4.3 安全加固：密钥、权限、注入，一个都不能少

密钥管理：绝不硬编码，绝不放环境变量
环境变量在 Lambda 控制台可见，且会被 CloudWatch Logs 记录（即使打码，也可能泄露）。正确姿势：

• 用 AWS Secrets Manager 存储数据库密码、API Key；
• 在函数配置中勾选“Enable encryption helpers”，Lambda 会自动解密；
• 权限策略中添加secretsmanager:GetSecretValue。

输入验证：防御 SQL 注入、XSS、路径遍历
Lambda 常暴露为公网 API，是攻击者首选目标。必须：

• 对所有event.pathParameters、event.queryStringParameters、event.body做白名单校验；
• 用path.join()处理文件路径，防止../../../etc/passwd；
• HTML 输出前做DOMPurify.sanitize()（Node.js）；
• 数据库查询用参数化语句（如 DynamoDB DocumentClient 的put({ TableName, Item })）。

最小权限策略：删掉所有“*”
检查你的执行角色策略，删除类似"Resource": "*"的宽泛授权。用具体 ARN：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/uploads/*" } ] }

4.4 版本与别名：让发布不再是一场豪赌

Lambda 的版本管理是灰度发布的基石。每次sam deploy会创建新版本（$LATEST），但直接调用$LATEST是危险的——你无法回滚，无法 AB 测试。

标准流程：

1. 部署后，发布新版本：aws lambda publish-version --function-name my-function；
2. 创建别名指向该版本：aws lambda create-alias --function-name my-function --name prod --function-version 1；
3. 所有生产流量调用prod别名，而非函数名；
4. 新版本测试通过后，用update-alias切换指向：aws lambda update-alias --function-name my-function --name prod --function-version 2。

进阶：加权流量路由（Traffic Shifting）
用别名实现 5% 流量切到新版本，观察指标（错误率、延迟）无异常后，逐步升到 100%。SAM 模板中配置：

MyFunctionAlias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref MyFunction FunctionVersion: !GetAtt MyFunction.Version RoutingConfig: AdditionalVersionWeights: "2": 0.05 # 5% 流量到版本 2

4.5 成本监控：别让 Lambda 成为账单黑洞

Lambda 费用 = 执行次数 × 执行时间 × 内存分配 × 单价。其中执行时间最难控。

必须监控的四大指标（CloudWatch Metrics）：

成本优化实战技巧：

• 用aws lambda list-functions --query 'Functions[?LastModified>=date -d "30 days ago" +%Y-%m-%d].FunctionName'定期清理 30 天未更新的函数；
• 对低频函数（<100 次/天），关闭 Provisioned Concurrency；
• 用 Cost Explorer 按function-name维度分析费用，找出“高内存低使用”的函数（如分配 3008MB 但平均只用 200ms）。

4.6 本地开发体验：告别“写完上传，等 2 分钟看日志”

SAM CLI 的sam local invoke和sam local start-api已很好，但还可升级：

推荐组合：

• VS Code + AWS Toolkit 插件：右键函数代码 → “Deploy SAM Application”，一键部署；右键 → “Invoke Locally”，直接传入事件 JSON 调试；
• Docker Compose 模拟下游服务：为本地测试搭建 mock RDS（PostgreSQL）、mock S3（MinIO）、mock SES（MailHog），避免调用真实服务产生费用或污染数据；
• Jest + AWS SDK Mock：单元测试不依赖网络，jest.mock('aws-sdk')拦截所有 SDK 调用，返回预设响应。

4.7 故障排查速查表：从报错信息直击根因

实操心得：我们曾因package.json里把axios放在devDependencies，导致线上Cannot find module 'axios'。后来强制规定：所有require()或import的模块，必须在dependencies中声明，CI 流程加入npm ls axios检查。

5. 常见问题与排查技巧实录——那些文档里找不到的答案

5.1 “为什么我的函数在本地跑得好好的，一上云就超时？”

这个问题我遇到过至少 12 次，90% 的原因是网络延迟被严重低估。本地测试时，你的笔记本直连互联网，DNS 解析、TCP 握手、TLS 握手都在毫秒级；而 Lambda 在 AWS 可用区，首次访问外部服务（如第三方 API）时，需经历：

• DNS 查询（Lambda 使用 Amazon DNS，但首次仍需缓存）；
• TCP 连接建立（跨可用区或跨区域时，RTT 可达 50~200ms）；
• TLS 握手（RSA 2048 密钥交换约 100ms，ECDHE 更快但需支持）；
• 第三方服务响应（你无法控制）。

解决方案：

• 复用连接：Node.js 中用https.Agent设置keepAlive: true，并增大maxSockets：

  const https = require('https'); const agent = new https.Agent({ keepAlive: true, maxSockets: 50 }); axios.create({ httpsAgent: agent });

• 预热连接：在函数初始化阶段（handler外）发起一次空请求，建立连接池：

  // 初始化时执行（只在冷启动时运行一次） let warmupPromise; if (!warmupPromise) { warmupPromise = axios.get('https://api.example.com/health', { timeout: 2000 }); } await warmupPromise;

• 用 VPC Endpoint 访问 AWS 服务：如访问 S3，用com.amazonaws.us-east-1.s3接口，避免走公网，延迟降至 10ms 内。

5.2 “如何在 Lambda 中读取大文件（>100MB）而不爆内存？”

Lambda 内存上限 10GB，但/tmp目录只有 512MB。读取大文件时，若用fs.readFileSync()，会一次性加载全部内容到内存，必然 OOM。

正确姿势：流式处理（Streaming）
以 S3 大文件为例：

const { S3Client, GetObjectCommand } = require('@aws-sdk/client-s3'); const s3Client = new S3Client({ region: 'us-east-1' }); exports.handler = async (event) => { const command = new GetObjectCommand({ Bucket: 'my-bucket', Key: 'large-file.zip' }); // 获取流，不加载全文 const response = await s3Client.send(command); // 用 stream.Transform 处理数据块 const transformer = new Transform({ transform(chunk, encoding, callback) { // 对每个 chunk 做处理（如解压、转换格式） const processed = processChunk(chunk); callback(null, processed); } }); // 管道：S3 Stream → Transformer → 目标（如 S3 另一 bucket） response.Body.pipe(transform