如何创建搭载iris及全量依赖的AWS Lambda层处理netCDF文件

反复出现补包后仍报缺失依赖的核心原因 #

这类报错并非逐个缺失Python包，本质是iris的依赖分为纯Python模块、带原生C/Fortran扩展的科学计算包、底层系统动态库三类。逐次根据报错提示补Python包的操作，没有匹配Lambda运行时的CPU架构、glibc版本和动态库搜索路径，很多底层库加载失败的报错会被Python导入逻辑包装成“缺失某Python包”的提示，最终形成无限补包的循环。

必须配置的全量依赖清单 #

第一类：适配Lambda运行时的Python依赖包 #

所有Python包需统一放置在Lambda层的python/目录下，需确保包的架构、版本和Lambda使用的Python runtime完全匹配，不能直接从本地开发环境打包上传：

• iris 核心本体
• numpy、scipy（需选择与Amazon Linux 2镜像glibc 2.26兼容的预编译wheel版本）
• netCDF4、h5py（iris读取netCDF文件的核心后端）
• cf-units、cftime（netCDF坐标和单位处理的核心依赖）
• matplotlib、networkx、shapely、pyproj
• python-dateutil、pytz、setuptools、six、typing-extensions

第二类：必须配套的系统级动态库 #

这类库无法通过pip安装，需统一放置在Lambda层的lib/目录下，运行时会自动被加入动态库搜索路径：

• libnetcdf（netCDF4包的底层依赖）
• libhdf5（netCDF4、h5py包的底层依赖）
• libudunits2（cf-units处理单位转换的强制依赖，同时需配套完整的udunits2单位数据库文件）
• libgfortran（numpy、scipy的Fortran编译依赖）

常见避坑提示 #

• 不要跟着报错提示逐次补包：很多类似“缺失_netCDF4”“缺失_cf_units”的报错，本质是底层动态库找不到，并非Python包本身缺失，补对应的Python包完全无法解决问题
• Lambda层的CPU架构必须和函数完全匹配：x86架构的函数不能使用arm64架构编译的层，反之亦然，架构不匹配时所有带原生扩展的包都会加载失败，表现为持续报缺依赖
• 层内目录结构必须符合Lambda规范：Python包必须放在层根目录下的python/文件夹，动态库必须放在层根目录下的lib/文件夹，放错路径就算文件存在也会被判定为缺失

正确的全量层构建流程可一次完成配置，无需反复补包：在和Lambda runtime完全一致的Amazon Linux 2容器内完成所有上述系统库安装和Python包安装，直接将/opt目录下的内容打包为层zip即可。

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