Node.js转TypeScript后AWS Lambda模块识别失败求解决方案

方案一：统一使用ES模块适配Lambda（推荐） #

问题核心是Lambda Node16 runtime默认将.js文件视为CommonJS，而你打包的是ES模块，导致import语句报错。只需让Lambda识别你的代码为ES模块即可：

1. 修改打包输出为.mjs后缀
   更新package.json里的build和postbuild脚本，将输出文件改为handler.mjs：

   "scripts": {
     "prebuild": "rm -rf dist",
     "build": "esbuild handler.ts --bundle --minify --sourcemap --platform=node --target=esnext --format=esm --outfile=dist/handler.mjs",
     "postbuild": "cd dist && zip -r handler.zip handler.mjs*"
   }
   

2. 更新Lambda函数的处理程序配置
   登录AWS控制台，找到你的Lambda函数，在「配置」->「常规配置」里，将「处理程序」修改为handler.mjs::lambdaHandler（注意后缀是.mjs，指向你导出的lambdaHandler）。
3. 重新部署
   执行原部署命令，重新上传打包后的zip包即可。

这样本地保持ES模块的开发体验，云端Lambda也能正确识别ES模块代码，两边都不会报错。

方案二：分离本地开发与生产构建配置 #

如果不想改动文件后缀，可以针对本地和生产分别用ES模块和CommonJS：

1. 修改生产打包为CommonJS格式
   更新package.json的build脚本，将format改为cjs：

   "build": "esbuild handler.ts --bundle --minify --sourcemap --platform=node --target=esnext --format=cjs --outfile=dist/handler.js"
   

2. 保持本地ES模块配置不变
   你的package.json保留"type": "module"，tsconfig.json也维持原module: "esnext"配置，确保本地开发时正常运行。
3. 重新部署
   执行部署命令上传CommonJS格式的打包文件，Lambda默认支持CommonJS，不会出现import语句错误。

这个方案的核心是让生产构建输出Lambda原生支持的CommonJS，本地继续用ES模块开发，避免两边的配置冲突。

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