未安装依赖的Lambda层为何能支撑Lambda函数正常运行？

结合你的描述，以下是几种可能导致该现象的原因：

1. 函数部署包中意外包含sqlalchemy #

虽然你认为Lambda函数本身未安装sqlalchemy，但可能构建或部署过程中存在疏漏：

• 本地开发时的虚拟环境依赖被误打包进函数部署包；
• 函数的构建脚本中存在其他未注意到的pip install命令，将sqlalchemy安装到了函数代码目录；
• 之前部署的函数包残留了sqlalchemy文件，后续部署未完全覆盖。

验证方法：下载Lambda函数的部署包并解压，检查是否存在sqlalchemy相关目录或文件；也可在Lambda控制台的「代码」标签页中直接查看文件结构。

2. 层版本引用错误 #

你提到仅使用层版本控制，可能存在以下情况：

• 函数实际关联的是已安装sqlalchemy的旧层版本，而非你测试的未安装版本；
• CloudFormation模板中的层版本号未更新，导致部署后函数仍指向旧版本层。

验证方法：在Lambda控制台的函数配置中查看关联层的ARN，确认版本号是否与你测试的未安装版本一致；或通过CloudFormation栈的输出/资源详情检查层版本的实际关联情况。

3. 函数关联了其他包含sqlalchemy的层 #

Lambda函数可以同时关联多个层，可能你只检查了自己的目标层，忽略了其他已关联的层：

• 函数可能还引用了其他第三方层或内部层，其中包含sqlalchemy依赖；
• 之前的部署操作中添加了未被移除的额外层。

验证方法：查看Lambda函数配置中的「层」列表，检查所有关联层的内容，确认是否有层包含sqlalchemy。

4. 代码逻辑未实际触发sqlalchemy的使用 #

虽然代码中存在from sqlalchemy.orm import Session的导入语句，但可能测试场景下并未执行到依赖该库的代码分支：

• 导入语句被包裹在条件判断中，测试时未满足触发条件；
• 代码中存在try-except捕获导入异常，并提供了备选逻辑（如使用其他数据库连接方式）。

验证方法：在函数中添加日志，打印sqlalchemy.__version__（若导入成功），或在使用Session的代码前后添加日志，确认该部分代码是否实际执行；也可故意触发数据库上传逻辑，观察是否出现报错。

5. Lambda执行环境的热启动缓存 #

Lambda的热启动会复用之前的执行环境，若你在更换层版本前，函数曾在包含sqlalchemy的环境中运行过，后续的热启动请求可能仍复用该缓存环境：

• 即使层版本已更新，热容器中的依赖不会自动清除，直到容器被销毁。

验证方法：修改函数代码（如添加一个空行）并重新部署，强制触发冷启动，再次测试函数是否还能正常运行。

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