本地VSCode运行正常的App部署Lambda后失效且无CloudWatch报错

你的问题核心在于异步流程控制不规范和错误处理不到位，导致Lambda提前终止或错误信息被隐藏，具体问题点和修复方案如下：

1. 混合async/await与.then/.catch的隐患 #

你当前代码同时使用了await和.then/.catch链式调用，这种混合写法极易导致异步流程失控——Lambda的async函数需要等待所有异步操作完成才会正常结束，而链式调用中的异步逻辑如果没有正确传递Promise，可能会被Lambda误认为执行已完成，提前终止进程，进而导致后续的downloadFile、sendToDrive等操作未完成就被中断。

2. 错误处理无效 #

你的.catch仅打印了字符串"error"，没有输出具体错误对象的信息（比如error.message、error.stack），这直接导致CloudWatch中看不到任何有用的报错细节，无法定位问题根源。

修复后的代码示例 #

module.exports.fetch = async event => {
  try {
    // 获取SSM参数
    const getParametersResponse = await ssm.getParameters({
      Names: ["TOKEN", "ACCESS_KEY"]
    });

    // 改用纯async/await写法，避免链式调用的流程混乱
    const res = await axios.get(url);
    await downloadFile(res.data, project);
    
    const readStream = await zipFile.openReadStream(entry);
    await sendToDrive(readStream, project, gdriveKey);

  } catch (error) {
    // 打印完整错误信息，包括堆栈轨迹，方便排查问题
    console.error("执行出错:", error);
    // 抛出错误让Lambda标记为执行失败，便于监控告警
    throw error;
  }
};

额外排查点 #

• 确认ssm、axios、zipFile、entry、project、gdriveKey等变量是否在函数内正确初始化或传入：本地运行正常但Lambda失败，大概率是环境变量、权限或资源引用问题（比如Lambda没有SSM参数读取权限，或zipFile依赖的文件在Lambda环境中不存在）。
• 检查Lambda执行角色权限：确保角色拥有SSM参数读取权限、目标URL的网络访问权限（若为VPC内Lambda，需确认网络配置可访问外部）、Google Drive相关操作权限等。
• 验证CloudWatch日志配置：有时日志存在延迟，或日志组配置异常导致无法输出，需确认日志组正常关联Lambda且有写入权限。

内容的提问来源于stack exchange，提问作者Lucas.Pheliny