AWS Lambda（无服务器）是否支持像运行一次性函数一样安装应用？

以下是针对你提出的几个问题的具体说明： #

依赖的处理与安装位置 #

Lambda的依赖有三种主流处理方案，可根据依赖体积和复杂度选择：

• 直接打包进函数部署包：将依赖和业务代码一起打包为ZIP包上传，例如Python项目执行pip install -r requirements.txt -t .后和代码一起打包，Node.js项目直接将node_modules目录一起打包。这种方案适合依赖量小的简单函数，ZIP包上传限制为50MB，解压后总大小不能超过250MB。
• 封装为Lambda层（Lambda Layer）：把公共依赖单独打包为层，多个同运行时的函数可以共享同一个层，避免重复打包。层的大小也计入250MB的解压总配额，单个函数最多绑定5个层。
• 容器镜像部署：如果依赖体积大、配置复杂，可以将运行环境、依赖、代码一起打包为符合OCI标准的容器镜像，上传到Amazon ECR后直接作为Lambda的运行载体，镜像最大支持10GB，完全满足复杂应用的需求。

安装配置是否会每次启动重复执行 #

不会。Lambda的运行分为冷启动和热启动两个阶段：
只有首次触发、或长时间没有请求导致原有实例被回收后，才会触发冷启动：拉取部署包/层/镜像、执行全局初始化代码、加载依赖，这一步才会执行安装配置逻辑。
只要实例处于存活状态（空闲状态下通常会保留几分钟到几十分钟，具体由Lambda调度策略决定），后续的请求都会走热启动，直接复用已初始化好的运行环境，不会重复执行依赖安装和配置操作。
注意不要把依赖安装、全局初始化的逻辑写在函数处理程序（handler）内部，否则每次请求都会重复执行，建议放到handler外部的全局作用域，仅在冷启动时执行一次。

大体积/复杂配置应用的冷启动耗时问题 #

如果完全用默认配置，大体积应用的冷启动确实会有明显耗时，可通过以下方案优化：

• 精简依赖：只保留运行必要的组件，移除冗余的文档、测试用例、未使用的可选依赖，减小部署包体积
• 启用预置并发：提前预留指定数量的已完成初始化的Lambda实例，请求到达后直接处理，完全消除冷启动耗时
• 使用SnapStart（仅支持Java运行时）：Lambda会自动对完成初始化的运行环境生成快照，冷启动时直接恢复快照，最多可减少90%的启动耗时
• 优先选择容器镜像部署：大体积依赖用容器镜像的加载效率远高于零散的ZIP包，能有效减少冷启动耗时

依赖的存储与调用逻辑 #

Lambda底层的计算资源确实是AWS托管的EC2集群，但这部分资源完全由AWS管理，用户无权限直接访问。
你打包的依赖、镜像会存储在AWS内部的存储服务中，冷启动时才会拉取到分配给你的隔离沙箱环境中，实例存活期间依赖会保存在沙箱的本地存储中，实例被回收后沙箱会被完全销毁，不会残留任何你的数据和依赖。不存在提前将软件安装到某台固定EC2实例、随用随调的情况，所有运行环境都是按需分配、租户隔离的。

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