API Gateway触发的Lambda启动后卡住超时、首行console.log不打印如何排查？

从提供的日志来看，Lambda实例正常启动，内存已打满128M配置上限，且handler内部第一行日志无输出，说明阻塞发生在handler执行前的初始化阶段，可从以下方向排查：

1. 全局初始化逻辑阻塞 #

• 检查handler函数外部的全局代码：是否存在同步高耗时操作，包括大体积依赖引入、同步读取超大本地文件、重度加密/哈希计算逻辑，这类逻辑会在handler执行前完成，耗时过长会直接触发超时
• 检查全局异步逻辑是否未合理处理：如果全局代码存在未捕获的Promise rejection、无限等待的异步调用，会导致初始化流程卡住，无法进入handler执行阶段

2. 内存不足问题 #

日志显示Max Memory Used: 128 MB已经触达配置上限，内存不足会触发Node.js持续GC甚至进程卡死，无日志输出：

• 临时将Lambda内存配置调高到512M重试，如果超时问题消失，说明原128M内存不足以支撑初始化阶段的资源消耗，可选择优化依赖减小体积，或者上调内存配置
• 检查npm依赖引入是否合理：是否引入了冗余的大体积依赖，比如完整引入aws-sdk v2而不是使用aws-sdk v3的模块化按需引入，是否将devDependencies错误打包到了生产产物中

3. 网络与权限配置问题 #

如果初始化阶段存在外部服务调用，网络/权限不通会导致调用卡住超时：

• 检查Lambda是否绑定了VPC：如果绑定了VPC但未配置正确的子网路由、安全组出站规则，初始化阶段调用VPC内资源（如RDS、Redis）或公网接口会因为网络不可达卡住
• 检查Lambda执行角色权限：如果初始化阶段调用了AWS服务（如从SSM Parameter Store、Secrets Manager拉取配置），执行角色缺少对应操作权限会导致调用被拒绝，未捕获异常的情况下无日志输出

4. TypeScript + CDK 专属配置问题 #

• 检查CDK构造配置：如果使用NodejsFunction构造，确认bundling配置是否正确，是否存在打包规则错误导致产物异常；如果使用自定义打包逻辑，确认handler入口路径配置正确，路径错误会导致Lambda找不到入口函数，直接卡住超时
• 检查TypeScript编译配置：确认编译target版本和Lambda Node.js运行时版本兼容，是否错误使用了ESM模块化规范而Lambda运行时默认使用CommonJS，导致模块加载失败卡住

内容的提问来源于stack exchange，提问作者Moshe Shaham