AWS Lambda偶发cannot find module及Runtime.ImportModuleError报错求助

1. 打包路径结构不符合Lambda要求 #

• Lambda要求业务代码、node_modules目录必须放在压缩包的根目录，如果打包时选中了外层项目文件夹压缩，解压后第一层为项目文件夹，运行时就会在根目录找不到对应模块
• 偶发特征对应：手动打包时偶尔选中文件夹内所有文件压缩、偶尔选中外层文件夹压缩，就会出现打包后有时正常有时报错的情况；自动打包脚本如果工作目录执行异常，也会导致生成的zip包结构不稳定

2. 压缩工具的配置问题 #

• 部分压缩工具默认会丢弃node_modules中的软链接、隐藏文件或者权限标识，比如7zip如果未开启保留软链接的配置，会将npm生成的包引用软链接转为普通文件/直接丢弃，导致模块引用路径断裂
• 偶发特征对应：不同压缩工具、同工具不同参数生成的包结构有差异，就会出现换压缩工具后报错模块变化的情况

3. 依赖兼容性与打包缓存问题 #

• 本地开发环境（Windows/macOS）安装的带有二进制编译产物的依赖（比如需要node-gyp编译的包）和Lambda的Amazon Linux运行环境不兼容，只有跨平台版本的依赖包能正常运行
• aws-sdk为Lambda Node.js运行时内置依赖，打包时如果传入了和内置版本冲突的aws-sdk，会触发模块加载冲突，移除后相当于直接使用内置版本，暂时规避问题
• 本地node_modules缓存损坏、或者打包时偶尔遗漏部分依赖文件，会导致同一份代码打包出来的产物不固定，出现重复打包后有时正常有时报错的情况

4. Lambda部署的最终一致性问题 #

• Lambda新代码包上传后存在异步同步窗口期，此时触发的请求可能还是运行旧版本代码，或者新包同步不完整
• Lambda冷启动容器存在缓存，若之前错误版本的容器还未被回收，即使你上传了正确的包，依然会返回错误；等错误容器过期回收后，新的冷启动拉取到正确的包就会恢复正常，符合未做任何修改功能自动恢复的特征

5. 动态导入/可选依赖加载问题 #

• 如果代码中存在动态import()逻辑，或者依赖包含可选的peer依赖，打包工具的tree shaking逻辑可能偶尔将未被静态检测到的模块剔除，运行时触发对应逻辑时就会报模块不存在，未触发时运行正常

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