AWS Lambda下google-cloud-firestore导入失败及运行时安装问询

google-cloud-firestore 依赖的grpcio模块包含C语言编写的原生二进制扩展，本地（Windows/macOS/非Amazon Linux的本地Linux）环境下pip安装生成的包，和AWS Lambda运行时基于Amazon Linux 2/2023的架构、系统库版本不兼容，最终触发导入失败。这也是为什么纯Python实现的requests模块用同样的打包方式能正常运行。

同架构环境构建适配的部署包 #

• 放弃本地直接pip安装后打包的方式，使用和Lambda运行时完全匹配的Docker镜像构建依赖：
  1. 拉取与Lambda所选Python版本、CPU架构对应的官方构建镜像，例如Python 3.11 x86架构对应镜像为amazon/aws-lambda-python:3.11
  2. 将本地业务代码目录挂载到容器内，在容器中执行pip install google-cloud-firestore -t ./，将所有依赖安装到业务代码目录下
  3. 将目录内所有文件直接压缩为ZIP部署包，确保lambda_function.py在压缩包根层级，不要额外嵌套一层文件夹
• 关键校验点：Lambda选arm64架构就用arm64版本的构建镜像，选x86_64架构就用x86_64版本的镜像，避免二进制兼容问题。

工具化自动构建减少手动操作误差 #

• 手动打包流程容易出现路径、架构不匹配的问题，可以直接使用AWS SAM、AWS CDK等官方部署工具，工具会自动在同架构的Lambda构建环境中拉取适配版本的依赖，直接生成可部署的包，无需手动处理原生扩展兼容问题。

用Lambda Layer托管公共依赖 #

• 将构建完成的适配版google-cloud-firestore相关依赖打包为独立的Lambda Layer，业务函数直接关联该Layer即可，无需每次部署都把依赖打进部署包，同时可大幅减小单函数部署包的体积。

• 不推荐在Lambda函数执行阶段临时安装依赖，原因如下：
  • Lambda除/tmp目录外，其余运行路径均为只读，无法全局安装Python包
  • 函数启动阶段安装依赖会大幅延长冷启动耗时，还可能因为网络超时、临时权限问题出现随机报错
  • Lambda执行环境为临时容器，每次冷启动都需要重复安装依赖，计算成本和时间成本都极高。

• 核对Python版本：本地构建环境的Python版本必须和Lambda所选运行时的Python版本完全一致，小版本不匹配也可能触发导入错误
• 避免直接打包虚拟环境内容：虚拟环境中的包和本地解释器路径强绑定，必须通过pip install -t 指定目录的方式把依赖独立到业务代码目录下再打包
• 若此前多次重装依赖仍报错，基本可判定是本地安装的grpcio二进制为本地平台版本，无法在Lambda环境运行。

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