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.medium4GB 内存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等字段的 JSONS3 事件则包含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 SAMServerless Application ModelCLI本地开发、测试、部署一体化。安装与初始化# 安装 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.yamlAWSTemplateFormatVersion: 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:testexample.com} # 4. 查看实时日志CtrlC 停止 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。这意味着分配 1024MBCPU 配额约为 0.57 个 vCPU分配 3008MB最大值CPU 配额 ≈ 1.68 个 vCPU。实测对比Node.js 18.x处理 1MB JSON 解析加密内存 (MB)平均执行时间 (ms)每次调用费用 ($)12821500.0000355128200.00002310244100.00002330082800.000031结论从 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但默认配置极易让你抓瞎。必须做的三件事启用 X-Ray 追踪在函数配置中开启 Active Tracing。X-Ray 会自动捕获函数执行时间、子调用如 DynamoDB 查询、S3 下载、错误堆栈并生成可视化调用链。没有它你无法定位“为什么这个 API 平均延迟 2 秒”——是函数本身慢还是下游 RDS 查询慢还是网络抖动结构化日志别用console.logconsole.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设置日志保留期默认永久保留但 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。若三次都失败消息进入 DLQDead 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/passwdHTML 输出前做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 测试。标准流程部署后发布新版本aws lambda publish-version --function-name my-function创建别名指向该版本aws lambda create-alias --function-name my-function --name prod --function-version 1所有生产流量调用prod别名而非函数名新版本测试通过后用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% 流量到版本 24.5 成本监控别让 Lambda 成为账单黑洞Lambda 费用 执行次数 × 执行时间 × 内存分配 × 单价。其中执行时间最难控。必须监控的四大指标CloudWatch Metrics指标名说明告警阈值Duration平均执行时间毫秒 1000ms同步或 30000ms异步Throttles被限流次数并发超限 0表示需调高并发配额Errors执行失败次数 5 次/5 分钟ConcurrentExecutions当前并发数 80% 预留并发或账户限制成本优化实战技巧用aws lambda list-functions --query Functions[?LastModifieddate -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 RDSPostgreSQL、mock S3MinIO、mock SESMailHog避免调用真实服务产生费用或污染数据Jest AWS SDK Mock单元测试不依赖网络jest.mock(aws-sdk)拦截所有 SDK 调用返回预设响应。4.7 故障排查速查表从报错信息直击根因报错信息最可能原因排查步骤Task timed out函数执行超时或下游服务无响应1. 检查Timeout设置2. 代码中加console.time()定位耗时环节3. 用 X-Ray 查看子调用耗时Permission denied执行角色缺少权限1. 查看 CloudWatch Logs 中的AccessDeniedException2. 用 IAM Policy Simulator 验证策略3. 检查资源 ARN 是否拼写错误Process exited before completing request代码未await异步操作或return位置错误1. 确保所有异步操作都被await2.handler函数末尾无return语句时Lambda 会立即退出Connection refused访问 VPC 内资源失败1. 检查函数是否配置了 VPC、子网、安全组2. 安全组是否允许出站到目标端口3. 目标服务是否监听正确端口Cannot find module xxx依赖未正确打包1.sam build后检查.aws-sam/build/目录是否有node_modules2.package.json中dependencies是否包含xxx3. 避免用devDependencies安装运行时依赖实操心得我们曾因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~200msTLS 握手RSA 2048 密钥交换约 100msECDHE 更快但需支持第三方服务响应你无法控制。解决方案复用连接Node.js 中用https.Agent设置keepAlive: true并增大maxSocketsconst 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