如何将Node模块存储在S3桶中供AWS Lambda使用以解决代码大小超限问题

方案1：使用AWS Lambda层（官方首选方案） #

• Lambda层是AWS官方提供的公共依赖托管能力，原生支持依赖与业务代码分离，无需修改业务逻辑
• 操作步骤：将全部node_modules放在名为nodejs的文件夹下，打包为zip包，上传为Lambda层；单个层最大支持250MB解压后体积，完全覆盖你的43MB依赖需求
• 部署业务代码时，仅需要打包7MB的业务逻辑上传，在函数配置中关联刚才创建的层即可。Lambda运行时会自动将层内的node_modules加入模块搜索路径，原有require/import语句不需要做任何修改
• 额外优势：层支持多函数复用，不会额外增加冷启动耗时，不需要额外配置权限

方案2：依赖包存S3，运行时动态拉取 #

如果你因特殊规则无法使用Lambda层，可以采用你提到的S3存储方案：

• 第一步：将node_modules打包为zip，上传到同区域的S3桶，为Lambda的执行角色配置该桶的s3:GetObject权限
• 第二步：在业务代码入口最前端增加初始化逻辑：函数冷启动时先判断/tmp/node_modules目录是否存在，不存在则从S3拉取依赖zip包，解压到/tmp目录下
• 第三步：修改Node模块搜索路径，将/tmp/node_modules加入全局搜索路径，示例代码：

// 放在所有require语句之前
require('module').globalPaths.unshift('/tmp/node_modules');

• 注意事项：Lambda的/tmp目录最大支持512MB存储，足够存放你的依赖；该方案会增加几十到一百毫秒左右的冷启动耗时，对冷启动延迟敏感的业务谨慎选择

优化建议：优先尝试依赖瘦身 #

你可以先尝试压缩node_modules体积，可能不需要做依赖拆分即可满足直传限制：

• 安装依赖时执行npm install --production，打包时执行npm prune --production，剔除所有devDependencies
• 使用npm dedupe或者pnpm作为包管理器，抹平多版本依赖重复安装的冗余
• 大体积单依赖替换为轻量替代包，比如将全量lodash替换为按需引入的单功能包
• 使用esbuild、webpack等工具对全量代码做tree shaking和压缩，仅保留实际被调用的依赖代码，多数场景下可以将整体打包体积压缩50%以上

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