企业官网建设流程全解析

1. 先用一张场景判断清单过一遍：你的业务到底适不适合上 Serverless

大概两年前，我第一次把真正业务切上 AWS Lambda，前后返工了三次，浪费了整整一周。坦白讲，Serverless 这个词被市场上很多文章捧成了"云原生银弹"，但实际用过的人都会发现：Lambda 解决的是"把运维复杂度换成运营成本"的问题，而不是"代码写得烂也能跑得爽"的问题。如果你正打算把项目迁到 Lambda，或者正在面试中被"无服务器架构"这个词搞得焦虑，那这篇文章应该能帮你少走不少弯路。

我对 Lambda 的真实定位是：它适合事件驱动型任务、突发流量型 API、以及团队人手紧张时的"胶水逻辑"。不适合长期稳定高吞吐的核心链路，也不适合对冷启动极其敏感、需要长连接的业务。我的建议是，先把业务拆成"哪部分是无状态的、哪部分是突发性的、哪部分是低频的"，再决定要不要上 Serverless。这套判断逻辑，比看任何性能报告都重要。

1.1 我为什么被 Lambda 吸引，又差点被它劝退

先说入坑的理由。我当时负责一个中小型团队的数据处理平台，每天要处理几十万条来自不同渠道的异步事件：文件上传后的格式转换、消息队列里的数据清洗、定时跑聚合任务。部署在 EC2 上的服务虽然功能完整，但一到深夜就没人管，扩容靠半夜惊醒。更头疼的是补丁更新、磁盘报警、进程守护这些"云主机保姆活"，让我感觉自己不是在做开发，而是在经营机房。

Lambda 最打动我的地方不是"按次数收费"，而是"完全不用管服务器"。这个感觉在你把第一个函数部署成功后，体验是很直观的：没有服务器、没有 SSH、没有安全组端口配置，生产环境从一个"需要治理的基础设施"变成了"一段可审计的代码"。我那时候一度膨胀到想把所有业务都搬上去。

劝退我的，是第一次把定时批处理任务迁上去。我按本地 Java 程序的思路写了个函数，里面跑了 20 分钟 SQL 聚合，完全没考虑 Lambda 的默认超时是 3 秒。线上跑起来直接 Task timed out，日志里只有一行冷冰冰的超时记录，我连从哪里开始查都不知道。然后我又遇到 Java 冷启动超 800 毫秒、函数代码包打包后依赖冲突、没有配 VPC 导致连不上 RDS……那一周我几乎每天都在给自己擦屁股。所以我的结论是：Lambda 不是不好，而是你必须在动手前想清楚"什么场景配对什么设计"。

1.2 适合与不适合的典型业务画像

我把自己这两年接触过的 Lambda 使用场景整理成了一张表，基本覆盖了大部分团队的实际选择逻辑：

注意这个"谨慎"的类别。我之前在社区看到不少人把订单系统直接挂在 Lambda 后面，结果大促时 QPS 一上来，冷启动加上 Java 的初始化时间，P99 延迟直接飙到 6 秒。不是 Lambda 不行，是在那种延迟敏感场景下，你需要为每个并发实例付预留费用，总成本很可能会超过一台稳定的 EC2。所以判断标准不是"能不能跑"，而是"成本与延迟是否可接受"。

1.3 成本模型：按调用次数付费的边界在哪里

Lambda 的计费由两部分组成：请求次数和 GB-秒。请求次数是每 100 万次 0.20 美元左右（具体价格随地区略有浮动），GB-秒则是按"内存（GB）乘以执行时间（秒）"累加。我举个直观的例子：一个 512MB 内存、平均执行 300ms 的函数，每调用一次约消耗 512/1024 × 0.3 = 0.15 GB-秒。一天的调用量如果在 10 万次，一个月大约 300 万次请求，费用大概就是请求费 0.6 美元加上 GB-秒费用。这个量级对绝大多数中小团队来说，比维护一台闲置 EC2 便宜得多。

边界在哪个位置？我自己的观察是：如果单个函数的日均调用量超过 100 万次，并且平均执行时间超过 1 秒，你就要认真算一算账了。此时 GB-秒的费用会快速累加，加上你可能为稳定延迟启动预留并发（预留并发按实例时长收费），总成本很容易超过同等规格 EC2 或容器服务。反过来，如果你有 20 个低频小函数，每个函数一天只被调用几十次，那 Lambda 的成本几乎可以忽略不计。我建议大家在迁移前用 AWS Pricing Calculator 先跑一遍对比，别拍脑袋决定，这个习惯能帮你避免上线后的成本惊吓。

2. 环境准备里最容易被卡住的三个点：账号、IAM 和本地工具链

环境准备这件事，看官方文档觉得很简单，真上手踩坑的全是细节。我的经验是，先别急着写函数，把账号、权限、本地工具链这三样理清楚，后面会顺畅很多。尤其是 IAM 权限，新手阶段我至少被各种 AccessDeniedException 折磨过十几次，每次都是跑到 CloudWatch 看日志才发现"哦，角色没绑对策略"。

2.1 AWS 账号和 IAM 角色的基础配置

如果你只有 AWS 账号但没有创建过 IAM 用户，建议不要直接用根账号做 Lambda 实验。不是说不能，而是根账号的 Access Key 一旦泄露，风险范围是整个账号。我一般都建议：创建一个专门用于开发的管理员用户，启用 MFA，只在命令行中配置这一组密钥。然后把生产环境的密钥跟开发环境分开，防止误操作。

Lambda 函数的运行身份是"执行角色"（Execution Role），不是你的用户身份。这一步很多人会忽略，结果本地调用正常、一部署到云端就报Lambda cannot access S3之类的错误。最简单的做法是在控制台创建函数时选择"创建新角色并附带基本权限模板"，Lambda 会自动生成带AWSLambdaBasicExecutionRole的策略，这个策略允许函数往 CloudWatch Logs 写日志。如果函数要访问 S3、DynamoDB、SQS，需要另外手动添加对应权限，原则是最小权限，别图省事直接挂AdministratorAccess。我曾经的同事就是这么干的，后来 key 泄露，对方直接遍历了他整个账号的 S3 桶，教训非常深刻。

2.2 SAM CLI 初始化与本地调试

官方推荐的本地开发方式有好几种，我个人最喜欢 AWS SAM（Serverless Application Model）。它的核心价值在于，用一套template.yaml描述函数、事件源、权限，然后sam deploy一键部署，本地还能用sam local invoke模拟调用。装好 AWS CLI 和 SAM CLI 后，一条命令就能创建一个 Java 项目：

sam init --runtime java17 --dependency-type maven --app-template hello-world -n serverless-demo

这个命令会生成一个标准的 Maven 项目，包含src/main/java下的 Handler 类和template.yaml。本地调试时我常用的两个命令：

sam local invoke --event event.json # 模拟一次事件调用 sam local start-api # 本地启动 API 网关

注意sam local依赖 Docker。我第一次跑的时候报了一个 docker not found，当时还很困惑，后来才意识到 SAM 是通过容器模拟 Lambda 运行环境的。调试 Java 函数时，本地环境与真实环境的差异主要在操作系统层面，但绝大部分逻辑错误都能在本地暴露出来，尤其是依赖注入、JSON 序列化这类问题。把"云端坏了"变成"本地能复现"，排查效率会高很多。

2.3 部署一个最简单的 Hello World 函数

SAM 项目的部署流程，我总结起来就三步：构建、部署、验证。第一次部署需要 Git 仓库没有也不影响，直接执行即可：

sam build sam deploy --guided

sam deploy --guided会问你几个问题，包括堆栈名、默认 Region、是否允许 IAM 角色创建等。回答完之后，SAM 会生成 CloudFormation 堆栈，自动创建 Lambda 函数、API Gateway 和对应的 IAM 角色。这一步跑通了，说明你的账号权限、工具链和网络都没问题。

验证也很简单，部署成功后 AWS CLI 会输出一个 API Gateway 的 URL，用curl请求即可：

curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/hello

收到 JSON 响应就说明最基础的链路已经通了。从这一步开始，后面所有的实战内容都有一个稳定的地基。我个人喜欢在项目初期就把"日志输出到 CloudWatch"这件事跑通，因为一个能查日志的 Lambda，才是一个"可排错"的 Lambda。

3. Java 函数实战：Handler、Lambda 表达式和内部类调用的那些坑

这部分是最多读者私信问我的内容，尤其是那几个高频搜索词：lambda 调用内部类示例、lambda 函数 java、lambda 表达式 java。很多人被 Java 的"既有 Lambda 表达式语法、又有 AWS Lambda 服务"搞混了。我在这里一并讲清楚。

3.1 Java Handler 的三种写法对比

AWS Lambda 的 Java 运行时，本质上是找你的代码里哪个方法是入口点。官方支持三种写法，我在实践中分别对比过：

实际项目里我基本都是用第一种，因为它对 POJO 反序列化的支持最好。一个标准的实现长这样：

public class HelloHandler implements RequestHandler<Map<String, String>, Map<String, Object>> { @Override public Map<String, Object> handleRequest(Map<String, String> input, Context context) { Map<String, Object> result = new HashMap<>(); result.put("statusCode", 200); result.put("body", "hello from lambda"); return result; } }

如果你只需要一个最简函数，也可以用方法签名的方式，直接声明public static String handler(String input, Context context)，AWS 会在运行时反射找到这个静态方法。但注意参数类型必须是String或InputStream这类框架能自动填充的类型，否则序列化阶段就会报错。

3.2 Java Lambda 表达式在函数体内的正确用法

聊完"作为服务的 Lambda"，现在说"作为 Java 语法的 lambda 表达式"。在 Handler 方法内部，你可以正常使用 Java 8 及以上的 lambda 表达式来处理业务逻辑。这本身没什么特别，但有几个细节值得注意。

首先是变量捕获的问题。lambda 表达式访问外部方法的局部变量时，该变量必须是 final 或 effectively final。很多新手会写成这样：

public String handleRequest(String input, Context context) { int count = 0; Function<String, Integer> f = s -> { count++; // 编译报错，count 不是 effectively final return s.length(); }; ... }

编译器会直接拒绝。解决办法是用原子类或者数组包装变量，但实际上更合理的思路是：把可变状态建模成一个局部对象，而不是尝试在 lambda 里修改外部变量。其次，lambda 表达式很适合配合 Stream 处理集合，比如从一个事件列表里过滤出符合规则的记录：

List<OrderItem> validItems = order.getItems().stream() .filter(item -> item.getStatus() == OrderStatus.PAID) .map(item -> item.applyDiscount(0.9)) .collect(Collectors.toList());

这种写法在 Lambda 函数处理批量事件时尤其顺手。SQS 触发时，事件里往往包含多条消息，用 Stream 做过滤和转换，代码会非常紧凑。

3.3 内部类调用 lambda 表达式的限制与规避

这是热词里"lambda 调用内部类示例"对应的真实场景。Java 中的内部类分为静态内部类、成员内部类（非静态）和匿名内部类，它们和 lambda 表达式之间有几个容易踩的坑。

第一个坑是序列化。AWS Lambda 处理事件时，默认用 Jackson 把 JSON 反序列化成你的 POJO。如果你定义了一个非静态内部类来接收事件，Jackson 会报No default constructor found之类的错误。原因是非静态内部类会隐式持有外部类的引用，它的构造器参数跟普通类不一致，无法被 Jackson 直接调用。解决方法是把事件类定义为静态内部类，或直接定义成独立文件。我曾在生产环境栽过一次，一个接收支付回调的类写成了非静态内部类，结果每次调用都报反序列化错误，排查了很久才发现问题不在业务代码而在类定义。

第二个坑是含义混淆。在非静态内部类里使用 lambda 表达式时，lambda 内的this指向的是外部实例还是内部类实例？Java 规范明确：lambda 表达式内部的this指代的是"包含 lambda 的那个外围类的当前实例"，而匿名内部类里的this指代的是匿名类自身。如果你在一个内部类的实例方法中写 lambda 并试图访问内部类自己的字段，直接用this.field可能拿到的是外部类的字段，或者干脆编译不过。要访问内部类的字段，可以用OuterClass.this.field或InnerClass.this.field语法显式区分。这个细节，我在代码评审中发现很多同事都搞混过。

其实规避这两个坑的关键，就是：事件 POJO 一律用静态类或独立类；lambda 表达式只在单纯无状态的转换逻辑里使用，不依赖隐式 this 引用。这样设计，序列化和逻辑清晰度都能保证。

3.4 事件类型与 POJO 绑定

AWS 事件源发来的 JSON，落到 Java 代码里就是一长串嵌套的 JSON 结构。手动写 String 解析既脆弱又痛苦，所以官方提供了aws-lambda-java-events库，里面有预定义好的APIGatewayProxyRequestEvent、S3Event、SQSEvent等类。在pom.xml里加依赖后，Handler 的参数直接填对应类型即可：

public class S3EventProcessor implements RequestHandler<S3Event, String> { @Override public String handleRequest(S3Event event, Context context) { event.getRecords().forEach(r -> { String sourceKey = r.getS3().getObject().getKey(); context.getLogger().log("Processing: " + sourceKey); }); return "ok"; } }

这里有个很容易忽略的点：Maven 打包时依赖的.jar不会自动进入最终部署包。如果你用mvn package生成的是瘦包，部署到 Lambda 运行时会直接ClassNotFoundException。我习惯在 pom 里配置maven-shade-plugin，把依赖打到一个 fat jar 里，或者用sam build让它自动化处理。否则你会发现本地跑得好好的，一上云就各种依赖缺失。

4. 从"能跑"到"好用"：内存、超时、重试与触发器配置

一个函数"能跑"和"好用到能上生产"，中间隔着一整套配置取舍。Lambda 的控制台虽然只有几个参数，但每个参数的背后都对应成本、延迟和可靠性的权衡。

4.1 内存与 CPU 的关系：别乱调 512MB

Lambda 允许你设置 128MB 到 10240MB 的内存，但很多人没注意到一个规则：内存设置决定了 CPU 配额。在 1769MB 内存以下时，CPU 是不成比例分配的，也就是说你设置 512MB 和 1024MB 时能获得的 CPU 算力差别很大。实际经验中，Java 函数的冷启动时间和内存强相关，因为更大的内存往往意味着 JVM 能分配更多资源，类加载也会更快一些。

我自己的压测数据（Java 17 运行时，函数逻辑简单）大致是这样的：

当然这只是参考值，不同函数差异很大，但趋势是一致的。我的建议是：先用 1024MB 起步，再用性能统计工具做一次压测，逐步往下调。另外要注意，Lambda 的并发配额是按"内存占比"计算的，区域默认并发上限一般是 1000，如果你把内存调到 2048MB，同一个函数能支撑的并发数就减半了。所以内存调大不仅影响单次成本，还会影响并发上限，需要一起权衡。

4.2 超时、重试和幂等设计

Lambda 默认超时是惊人的 3 秒。如果你没有显式调整，任何执行超过 3 秒的函数都会被强行杀掉。我第一次用 Java 写函数时就吃了这个亏，一个连数据库的聚合查询跑了十来秒，直接被 kill。在 SAM 模板里，超时是这样配置的：

Resources: MyFunction: Type: AWS::Serverless::Function Properties: Timeout: 60 MemorySize: 1024

超时设置需要结合业务实际。比如 API 网关触发的同步函数，建议控制在 10 秒以内，因为前端等太久本身就失去了体验。异步任务则可以放宽到 30 秒甚至更久。但请注意：单次 Lambda 最长只能跑 15 分钟，超过这个限制就必须拆分任务或者改用 Step Functions 编排。

比超时更隐蔽的是重试机制。异步触发（比如 S3、EventBridge、SQS）在函数执行失败后，Lambda 服务默认会重试两次。这个特性初衷是好的，但如果你的函数不是幂等的，重试就会造成重复扣费、重复发消息这类问题。我处理过一起线上事故：一个订单回调函数在超时后重试了两次，结果三条重复的"支付成功"消息被推给了业务方。从那以后我养成了一个习惯——凡是会改数据、发通知、调外部接口的函数，都必须带幂等键。幂等键最朴素的实现，就是事务号或消息 ID 去数据库里做唯一性校验；复杂一点可以用 DynamoDB 条件写入实现"这个 ID 处理过吗"的原子判断。

4.3 API Gateway 触发器与 S3/SQS 触发器的差异

Lambda 可以被很多事件源触发，但它们的行为差异很大。我在这里重点对比三个最常见的：

API Gateway 接入时，你需要关注授权方式。最简单的方式是绑定 IAM 授权或自定义 Authorizer，否则任何人拿到 API 地址都能调用你的函数，这在生产环境等于裸奔。S3 触发器配置时则要注意桶和函数必须在同一区域，而且要等函数配置好后再上传文件测试，因为 S3 的事件通知是"事后绑定"，你急着测试往往收不到事件。

SQS 触发器自带批处理功能，也就是说一次调用会把多条消息传给函数。这是个不错的优化点，尤其是 Java 函数冷启动成本高的时候，批处理能显著摊薄成本。我建议队列积压较多时把batchSize调到 10 左右，同时处理好"批里的某条消息失败时要不要整批失败"的策略。默认行为是整批失败然后全部重试，这样会重复处理成功过的消息。如果你期望部分成功，就要在代码里手动删除已成功的消息。

5. 冷启动、并发预留和 VPC：性能优化的三个实战选择

如果说前几节讲的是"跑起来"，这一节才是真正把 Lambda 调到"生产可用"的关键。冷启动、并发和 VPC 这三个话题，是 Java 工程师在 Serverless 世界里绕不开的硬骨头。

5.1 冷启动的成因与 Java 特有的痛点

冷启动的本质是：当 Lambda 收到一个请求，而当前没有空闲实例时，调度服务要做四件事——分配新容器、下载你的代码包、启动运行时、执行初始化逻辑。这个过程对 Java 特别不友好，因为 JVM 的启动和类加载本身就偏慢。我第一次用 Java 写 Lambda 时，冷启动平均在 1 到 2 秒，如果函数代码里用了 Spring，冷启动可以夸张到 6 秒以上。

应对思路有几种，按成本从低到高排列：

• 减少依赖：Spring Boot 这类重框架，在 Lambda 场景里能不用就不用。我自己后来把函数都换成了纯 Java + 轻量 JSON 库，冷启动降了一半以上。
• 切换到更轻的运行环境：如果业务允许，把纯脚本型函数放到 Python 或 Node 运行时，冷启动通常在 300ms 以内。
• GraalVM Native Image：你可以用 GraalVM 把 Java 函数编译成原生可执行文件，启动速度接近秒开。但副作用是反射和动态代理支持受限，很多框架用不了。
• Lambda SnapStart：这是 AWS 提供的官方优化方案，本质是把初始化快照缓存下来，恢复启动。开启后 Java 冷启动能降到 200ms 左右，但代码需要避免写入不安全的状态（比如随机数种子、Socket 连接等），官方文档列出了不少注意事项。

5.2 预留并发和 Provisioned Concurrency 怎么用

Lambda 默认按需扩容，但冷启动在突发流量面前就是一道"减速坎"。这时候就要用到预留并发（Reserved Concurrency）和预置并发（Provisioned Concurrency）了。

预留并发的含义是：给这个函数单独划出最多 X 个并发实例的额度，不能被其他函数抢占。它本身不解决冷启动问题，但它能保证你的函数不被并发上限卡死。预置并发更进一步，它会预先初始化好一部分实例，流量到达时直接复用，延迟就完全接近热调用了。

在 SAM 里配置预置并发很简单：

Resources: MyFunction: Type: AWS::Serverless::Function Properties: AutoPublishAlias: live ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 10

注意预置并发是按实例时长计费的，哪怕没有流量也收费。所以不要盲目设置很大的数值，要根据你的流量曲线和可用量预算来计算。我的习惯是：日常低谷只配 2-3 个实例兜底，大促前手动调到 20 个，活动结束后再降回来。这个过程可以结合 Application Auto Scaling 配置定时伸缩策略，用起来比较省心。

5.3 VPC 内 Lambda 的配置与 NAT 问题

当你的 Lambda 需要访问 RDS、Redis 或内网服务时，你必须把函数放进 VPC。这个动作本身不难，在控制台配置时选择子网和安全组即可。但有个非常经典的坑：Lambda 一旦接入 VPC，默认是没有公网 IP 的。如果你同时又要访问 S3 API 或外网服务，就会直接超时。

为什么会这样？因为 Lambda 的 VPC 模式本质上是把函数节点的 ENI 插入到你的子网里，而子网如果不带 NAT 网关/实例，就没有出去公网的路径。所以正确的架构必须是：Lambda 放在私有子网，同时创建一个 NAT 网关放在公有子网，路由表指向 NAT，函数才能访问外网。NAT 网关是按时收费的，一个 NAT 一个月大概 30 到 40 美元，小团队要注意这个额外成本。

另一个常见失误是安全组配置过于严格。Lambda 的 ENI 需要访问其他服务，安全组入站规则一般不用配置，但出站规则必须放行目标服务的端口。我曾经遇到过一个函数连不上 RDS，查了半天才发现是安全组只允许了 HTTP 出站流量，而数据库端口 3306 没有放行。

6. 排错实录：日志、X-Ray 和经典报错

最后说说排错。Lambda 的排错方式和传统服务器完全不同，你没有 SSH，没有 tcpdump，基本靠日志和链路追踪。把排错方法掌握扎实，你会发现绝大多数问题都能够在十分钟内定位。

6.1 CloudWatch 日志和日志组权限

Lambda 的 stdout 和日志输出会自动发送到 CloudWatch Logs。你只需要在函数里用System.out.println，或者更好一点，直接用context.getLogger().log(...)。这些日志会出现在以/aws/lambda/函数名命名的日志组里。

但要注意：日志能写进去，前提是你给函数挂了AWSLambdaBasicExecutionRole策略。如果你自己创建了一个"什么都没有"的角色，控制台测试时往往能看到结果，但日志组里是空的。排查这个问题时，先去 IAM 控制台确认角色策略，再去 CloudWatch 日志组确认是否存在。我遇到过好几次，函数明明打印了日志，CloudWatch 里却看不到，最后都指向角色缺权限。

调试时我喜欢用sam logs命令实时追踪日志：

sam logs --stack-name serverless-demo --tail

这个命令会拉取整个 CloudFormation 堆栈里所有函数的日志流，非常直观。比去控制台一个个点日志组高效多了。

6.2 三个高频报错和解决路径

我把这两年遇到的高频报错整理出来，每一条都附上排查路径：

Task timed out是最常见的新手报错，也是最容易误导人的。它只说明执行超过了设定时限，并不代表代码死循环。我曾经在排查一个数据库连接超时的函数时，把日志翻了个底朝天，其实问题就是 RDS 白名单没加 Lambda 的安全组，导致连接一直挂起，直到超时。所以看到这个报错，我的第一动作是去 CloudWatch 看最近一次日志的输出位置——如果日志只停在"准备连接数据库"，那大概率是网络或权限问题。

GLIBC报错多见于你用本地 macOS 或其他系统编译了 native 库。Lambda 的运行环境基于 Amazon Linux 2，glibc 版本较老，本地编译出的二进制不兼容。遇到这种情况，最省事的方式是在 Lambda 的环境里用aws-lambda-cpp或打包一个静态编译版本，而不是试图升级云端系统。

6.3 我踩过的序列化坑：内部类与 JSON 反序列化

这一节我想单独展开，因为"lambda 调用内部类示例"这个搜索词背后的诉求，本质上就是"Java 内部类在 Lambda 服务里怎么用"。太多人被限定在"如何写内部类"的语法层面，而忽略了运行时行为。

我举一个真实案例。某个函数接收的是一个支付回调事件，我图省事把返回的 JSON 类定义为 Handler 内部的非静态类：

public class PaymentHandler implements RequestHandler<Map<String, String>, String> { class CallbackData { String orderId; int amount; } ... }

部署后每次调用都报 Jackson 反序列化错误。因为非静态内部类的构造器签名是PaymentHandler$CallbackData(PaymentHandler)，Jackson 无法调用，它只会寻找无参构造器。解决办法有三种：第一，把CallbackData改成static class；第二，写在独立.java文件里；第三，用RequestStreamHandler自己拿 JSON 字符串手动解析（不推荐，太麻烦）。

同时还要提醒一个更隐蔽的现象：Java lambda 表达式里访问局部变量会隐式拷贝一份"值"，而访问实例字段时访问的是"this"。如果在匿名内部类或 lambda 里修改了状态，导致结果不一致，多半是因为你没有厘清"值捕获"和"引用捕获"的区别。这个知识点不只在 AWS Lambda 里有用，在写任何 Java 并发代码时都会用到。

6.4 结合 X-Ray 做端到端链路排查

当函数变多，一个请求可能包含 API Gateway、Lambda、SQS、另一个 Lambda、DynamoDB，排错就不能只看单个函数的日志了。这时我强烈建议开启 AWS X-Ray。在 SAM 模板里加上这两行：

Globals: Function: Tracing: Active

开启后，每次调用的耗时会在 X-Ray 控制台生成一条 Trace，你能直观看到时间花在哪个环节。有一次我发现某个函数调 Slow 到 5 秒，单独看日志看不出问题，用 X-Ray 一看，发现 85% 的时间都耗在 DynamoDB Scan 上，这比猜"网络不好"要高效得多。X-Ray 需要引入对应的 SDK 依赖，Java 中通常是：

<dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-xray-recorder-sdk-core</artifactId> </dependency>

在正式环境长期开着 X-Ray 会有少量成本，但对比排查事故所花的人力，这点费用是值的。

最后说一点我的个人感受：Lambda 并不是一套"写完就完事"的技术，它把运维工作量转移到了架构设计与配置细节上。我在实际项目中体会到，真正让人头疼的不是写函数本身，而是那些边界条件——超时、重试、幂等、VPC、并发预留、序列化。每解决一个，你对 Serverless 的理解就会加深一层。如果你正在用 Java 做 Serverless 项目，建议把上面这几个知识点逐个在你的项目里验证一遍，尤其是幂等设计和内部类的序列化问题，这两个最容易在流量上来时给你"惊喜"。