如何在.NET AWS Lambda Docker镜像中解决libwkhtmltox.so引用问题（.NET 2.1升级至3.1+场景）

云原生阿岚

2026-5-6

排查.NET Lambda中WkHtmlToPdf依赖缺失问题的建议

针对你在将.NET 2.1 Lambda升级到3.1+版本后，遇到的libjpeg.so.62缺失导致libwkhtmltox.so无法加载的问题，这里有几个具体的排查和解决方向：

检查Lambda基础镜像的系统依赖
Lambda默认使用的Amazon Linux 2或Amazon Linux 2023镜像中，默认的libjpeg版本可能不是wkhtmltox需要的62版本。比如Amazon Linux 2中默认提供的是libjpeg-turbo，你可以在Dockerfile中添加安装兼容依赖的步骤：
```
# 针对Amazon Linux 2基础镜像
RUN yum install -y libjpeg-turbo libjpeg-turbo-devel
```
如果是Amazon Linux 2023，改用dnf命令：
```
RUN dnf install -y libjpeg-turbo libjpeg-turbo-devel
```
验证依赖库的路径与环境变量
从你的日志来看，系统能找到libwkhtmltox.so，但找不到它的依赖。可以尝试在Lambda的环境变量中调整LD_LIBRARY_PATH，把系统默认的库目录和你的native库目录都包含进去：
```
LD_LIBRARY_PATH=/var/task/runtimes/linux-x64/native:/usr/lib64:/lib64
```
这样系统会在这些路径下查找缺失的libjpeg.so.62。
本地容器镜像中检查依赖完整性
本地构建Lambda镜像后，通过容器命令进入镜像内部，用ldd工具检查libwkhtmltox.so的所有依赖项：
```
docker run -it --rm <你的镜像名称> bash
ldd /var/task/runtimes/linux-x64/native/libwkhtmltox.so
```
这个命令会列出所有依赖的库及其状态，能明确看到除了libjpeg.so.62外是否还有其他缺失的依赖，再针对性安装。
确认架构与包版本匹配
日志中同时出现了linux-x64和linux-x86的路径，要确保你的Lambda运行架构设置为x64（如果用的是x64的wkhtmltox库），同时NuGet包WkHtmlToPdf-DotNet的版本是针对linux-x64的，避免架构不匹配导致的依赖加载问题。
尝试静态编译版的wkhtmltox库
有些预编译的wkhtmltox版本是静态链接所有依赖的，这样就不需要系统提供libjpeg等库。你可以替换项目中使用的libwkhtmltox.so为静态编译的linux-x64版本，彻底规避系统依赖缺失的问题。
确保Native库被正确部署
检查你的.csproj配置，确保libwkhtmltox.so文件被正确复制到发布目录：
```
<ItemGroup>
  <None Include="runtimes/linux-x64/native/libwkhtmltox.so">
    <CopyToPublishDirectory>Always</CopyToPublishDirectory>
  </None>
</ItemGroup>
```
容器部署时，也要确认Dockerfile中的COPY或dotnet publish步骤把这些native文件包含到了/var/task目录下。

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