ASP.NET MVC使用Rotativa导出PDF服务器端触发QPaintDevice报错如何解决

你遇到的QPaintDevice: Cannot destroy paint device that is being painted报错是wkhtmltopdf依赖的Qt底层渲染引擎抛出的异常，触发的核心原因是你配置的页眉/页脚HTML在服务器环境无法被正常渲染：

• 不加页眉页脚时PDF导出正常，说明主体PDF的渲染逻辑没有问题
• 调试环境正常、服务器报错，本质是两个环境的运行权限、资源可访问性存在差异，调试时用的IIS Express以本地登录用户身份运行，对本地路径、站点资源的访问权限更高，部署到IIS后应用池默认身份权限较低，很容易出现资源访问被拦截的问题

• 首先验证页眉页脚HTML的路径有效性：你代码里的header和footer变量在服务器环境下生成的是本地绝对路径还是网络路径？如果是网络路径，要确认服务器本身能不能正常访问这个路径（比如有没有内网权限、域名解析是否正常、有没有身份验证拦截）；如果是本地文件路径，要确认IIS运行站点的应用池身份对这个路径有读取权限。
• 其次排查页眉页脚HTML的内容问题：把header和footer对应的HTML单独抽出来，放到服务器上直接用本地安装的wkhtmltopdf命令行跑测试，命令参考wkhtmltopdf --header-html 你的页眉路径 --footer-html 你的页脚路径 任意测试html路径 输出pdf路径，看命令行执行会不会报错，能直接定位是Rotativa封装的问题还是wkhtmltopdf本身的渲染问题。
• 检查HTML内的资源引用：如果页眉页脚里有引用图片、CSS、字体，全部换成服务器本地的绝对文件路径，不要用相对路径或者站点路由路径，Qt渲染引擎在加载页眉页脚的独立上下文里无法解析站点的相对路由。还有要避免使用Web字体，Qt旧版本对部分自定义字体支持有bug，会触发渲染崩溃。
• 验证参数转义是否正确：你当前的CustomSwitches用的是双引号包裹路径，部分Windows服务器环境下如果路径里有空格或者特殊字符，可能会出现参数解析错误，可以尝试把路径前后的双引号换成单引号，或者对路径里的特殊字符做转义处理。

• 最稳定的修复方案：把页眉页脚的HTML内容转换成内联的Base64 URI，彻底避免路径加载问题，示例代码如下：

// 读取页眉HTML内容，转Base64
var headerHtml = File.ReadAllText(Server.MapPath("~/Views/PdfTemplates/Header.html"));
var headerBase64 = Convert.ToBase64String(Encoding.UTF8.GetBytes(headerHtml));
var headerUri = $"data:text/html;base64,{headerBase64}";
// 页脚同理做同样转换
var footerHtml = File.ReadAllText(Server.MapPath("~/Views/PdfTemplates/Footer.html"));
var footerBase64 = Convert.ToBase64String(Encoding.UTF8.GetBytes(footerHtml));
var footerUri = $"data:text/html;base64,{footerBase64}";
// 赋值给CustomSwitches
CustomSwitches = string.Format("--header-html \"{0}\" --header-spacing 10 --footer-html \"{1}\"", headerUri, footerUri);

• 如果上述方案还是不行，可以降级使用wkhtmltopdf 0.12.5版本，这个版本对Qt渲染的异常容错更高，0.12.6之后的部分版本确实存在页眉页脚渲染崩溃的已知问题。
• 确认服务器上是否安装了Visual C++ Redistributable 2015-2022运行库，wkhtmltopdf运行依赖这个库，缺失的情况下也会偶发渲染报错。

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