为什么我的AWS Lambda在ARM64架构下运行会崩溃？

1. 启动阶段故障的日志获取与本地调试方法 #

• 首先开启Lambda运行时调试日志：在Lambda控制台配置页的「监控和运维工具」板块，找到运行时日志设置，将日志级别调整为DEBUG，开启运行时API全量日志记录，这部分日志会输出CLR初始化、程序集加载的全流程信息，不受业务代码日志初始化逻辑的限制，可以拿到启动早期的错误细节。
• 本地模拟调试：如果本地是Arm架构设备（M系列Mac、Arm Linux主机），直接使用AWS SAM CLI执行sam local invoke --parameter-overrides Architecture=arm64即可模拟arm64环境的Lambda运行过程；如果是x86设备，可以通过Docker拉起amazonlinux:2的arm64镜像，在容器内安装.NET 3.1 Arm版本运行时，将部署包解压后手动执行dotnet Lambda.Api.dll，就能复现启动报错并拿到完整的错误输出。
• 开启程序集绑定日志：在项目的.csproj文件中添加<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>配置，打包时会生成.runtimeconfig.dev.json文件，开启程序集绑定日志记录，启动失败时会直接输出绑定失败的具体原因。

2. 非依赖项导致的故障诱因 #

• 构建参数配置错误：如果在x86环境下打包时没有指定--runtime linux-arm64参数，生成的部署包默认适配x86架构，其中包含的运行时配置、原生绑定组件都无法在arm64环境下加载，直接触发程序集加载失败。
• Lambda运行时版本不匹配：.NET 3.1的官方托管运行时仅提供x86版本，arm64架构需要使用provided.al2自定义运行时，如果你没有修改运行时配置仅修改了架构参数，就会出现启动失败。
• 硬编码的架构专属路径：如果项目中硬编码了x86专属的依赖加载路径、Native库搜索路径，在arm64环境下会导致核心依赖找不到，触发主程序集加载失败。
• 强名称验证不通过：部分依赖包如果是针对x86架构强签名的，在arm64环境下加载时会触发强名称校验失败，直接抛出程序集加载异常。

3. 定位故障依赖包的方法 #

• 使用ldd工具排查原生依赖：在arm64的Linux环境下，进入部署包解压目录执行ldd *.dll，输出结果中标记为not found的就是缺失arm64版本的原生依赖。
• 遍历依赖包的架构支持：在项目根目录执行dotnet list package --include-transitive导出全量依赖列表，逐个检查每个依赖包对应版本的NuGet说明，确认是否支持linux-arm64运行时，不支持的包需要升级版本或者替换为适配arm64的替代包。
• 结合程序集绑定日志定位：开启绑定日志后，错误日志中会明确输出加载失败的程序集名称、版本号、请求加载的来源，可以直接定位到对应的依赖包。
• 手动加载测试：写一个简单的控制台测试程序，通过System.Reflection.Assembly.LoadFrom方法逐个加载部署包中的程序集，捕获加载过程中的异常即可直接定位到出错的依赖项。

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