如何在多个AWS Lambda函数间共享代码？直接导入VS Lambda Layers

我有一个包含多个Lambda函数的微服务，想了解如何在这些函数之间共享代码，当前目录结构如下：

handler
|
|______ a-handler.js
|
|______ b-handler.js
|
repository
|
|______ users-repository.js

我知道AWS推荐使用Lambda Layers实现代码共享，但能不能直接通过导入相关代码的方式实现？示例如下：

users-repository.js

export getUser(...){...}; 
export createUser(...){...}; 

a-handler.js

import {getUser} from '../repository/users-repository.js';
// ...业务逻辑

b-handler.js

import {createUser} from '../repository/users-repository.js';
// ...业务逻辑

由于构建过程会通过Tree Shaking移除未使用的代码，最终仅保留各函数所需的相关代码，那Lambda Layers的优势究竟是什么？

1. 避免重复构建与部署 #

直接导入的方式下，每个Lambda函数的构建包都会包含自己用到的共享代码片段。如果共享代码（比如这个users-repository.js）需要更新，你得重新构建并部署所有依赖它的Lambda函数。而用Lambda Layers的话，只需要更新Layer一次，所有关联的Lambda函数下次执行时就会自动加载新版本的共享代码，不用逐个操作函数，省了大量重复工作。

2. 精简函数包体积，规避大小限制 #

虽然Tree Shaking能去掉单个函数没用的代码，但如果共享代码本身包含大体积逻辑（比如复杂工具库、SDK封装集合），每个函数包还是会带上专属的副本。Lambda有部署包大小限制（当前是压缩后50MB、解压后250MB），用Layers的话，共享代码只存储一份，所有函数共用，能有效降低单个函数包的体积，避免触发限制。

3. 统一依赖与版本管理 #

如果共享代码涉及第三方依赖（比如特定版本的AWS SDK、自定义工具库），Layers可以把这些依赖统一托管，确保所有关联函数使用的依赖版本完全一致。要是用直接导入的方式，每个函数的构建流程都得单独处理依赖，很容易出现不同函数依赖版本不一致的情况，排查问题时会非常棘手。

4. 跨场景复用代码 #

Lambda Layers支持跨函数、跨CloudFormation栈甚至跨AWS账号复用（只要权限配置正确）。如果你的其他项目也需要用到users-repository这类共享代码，直接复用Layer即可；而直接导入的方式，你得把代码复制到每个项目，维护成本高，还容易出现代码不一致的问题。

5. 间接优化冷启动速度 #

当多个函数共享同一个Layer时，Lambda运行时可能会缓存该Layer的内容。不同函数冷启动时，不需要重复下载共享代码部分，一定程度上能加快冷启动速度。这个效果视场景而定，但也是Layers的一个实用潜在优势。

当然，直接导入的方式在小型项目里完全够用——比如只有两三个Lambda函数，共享代码逻辑简单，Tree Shaking后包体积很小，维护起来也不麻烦。但当项目规模扩大、Lambda函数增多、共享代码复杂度提升时，Lambda Layers的优势会越来越明显。

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