Transcribe流式SDK打包Lambda层时_awscrt模块缺失报错

• _awscrt 是awscrt SDK自带的C语言扩展二进制模块，无纯Python实现，不同操作系统、CPU架构对应的编译产物完全不通用。
• 你在本地主机环境执行pip3 install时，pip会自动下载匹配本地系统（如macOS、Windows）、本地CPU架构的awscrt安装包，这些二进制文件可以在本地虚拟环境正常运行，但无法在Lambda的Amazon Linux运行时上正常加载。哪怕单独手动安装awscrt，只要安装环境和Lambda运行时不匹配，就会触发模块导入失败的报错。
• 部分历史版本的amazon-transcribe SDK在依赖拉取逻辑上存在缺陷，本地安装时不会自动适配Lambda运行时的二进制版本，会进一步加剧跨环境不兼容的问题。

• 第一，在与Lambda运行时完全一致的容器环境中安装依赖，禁止直接在本地主机目录安装依赖后打包。操作路径如下：
  • 拉取和你Lambda函数运行时、CPU架构完全匹配的Lambda基础容器镜像，例如x86架构Python 3.10环境直接使用官方提供的对应版本Lambda运行时镜像。
  • 启动容器后，在容器内部执行依赖安装命令：pip3 install amazon-transcribe aiofile -t ./python，此时pip会自动下载匹配Amazon Linux架构的二进制版本依赖。
• 第二，严格遵循Lambda层的目录规范打包：所有依赖文件必须放在压缩包内的python子目录下，不要把依赖散在压缩包根目录，否则Lambda运行时的模块扫描路径无法识别到对应依赖。
• 第三，严格匹配CPU架构：如果Lambda函数是基于Graviton处理器的arm64架构，绝对不能使用x86架构环境下编译的依赖，必须重新在arm64版本的对应Lambda运行时容器中安装依赖后再打包。
• 第四，提前校验依赖完整性：解压最终上传的Lambda层压缩包，检查python/awscrt目录下是否存在对应Lambda架构的.so后缀二进制文件（例如x86环境下的_awscrt.cpython-310-x86_64-linux-gnu.so），如果目录下只有本地系统生成的.dylib（macOS）、.pyd（Windows）格式文件，说明依赖完全不兼容，需要重新安装。

踩坑提示：不要直接使用带跨平台参数的pip命令（如--platform指定linux平台）在本地跨系统安装依赖，旧版本pip对这类跨平台下载的依赖路径解析存在bug，极易漏装C扩展类模块。

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