.NET Core 2.0 Web API用PdfReport.Core返回PDF异常求助

我之前在做.NET Core返回PDF的时候也踩过类似的坑，结合你用的PdfReport.Core和给出的代码，给你几个可行的排查和修复方案：

1. 修复流的生命周期管理问题 #

你的代码直接返回FileStreamResult，但默认情况下这个结果会自动处置传入的MemoryStream。如果CreateStreamingPdfReport还没完全写完流，或者流被提前释放，就会导致PDF文件不完整、损坏。

更稳妥的方式是把流转换成字节数组，用FileContentResult返回，彻底规避流的生命周期问题：

[HttpGet]
[Route("api/v1/pdf")]
public IActionResult GetPDF() {
    using var outputStream = new MemoryStream();
    InMemoryPdfReport.CreateStreamingPdfReport(_hostingEnvironment.WebRootPath, outputStream);
    outputStream.Position = 0;
    
    // 把流转换成字节数组，再返回
    var pdfBytes = outputStream.ToArray();
    return File(pdfBytes, "application/pdf", "report.pdf");
}

如果坚持用FileStreamResult，记得手动设置不自动处置流：

return new FileStreamResult(outputStream, "application/pdf") { 
    FileDownloadName = "report.pdf",
    EnableRangeProcessing = false
};

2. 先验证PDF生成逻辑是否正常 #

有时候问题根本不在API返回环节，而是PDF本身生成就有问题。可以在本地保存生成的流，看看能不能正常打开：

using var outputStream = new MemoryStream();
InMemoryPdfReport.CreateStreamingPdfReport(_hostingEnvironment.WebRootPath, outputStream);
outputStream.Position = 0;

// 保存到本地测试
using var localFileStream = new FileStream(@"D:\test_report.pdf", FileMode.Create);
outputStream.CopyTo(localFileStream);

如果本地保存的PDF也损坏，那就要检查CreateStreamingPdfReport的逻辑了——比如模板路径是否正确、数据源是否完整、PdfReport.Core的配置有没有遗漏。

3. 排查Swashbuckle的测试干扰 #

Swashbuckle在测试二进制响应时，偶尔会对数据流做额外处理，导致文件损坏。你可以跳过Swagger，直接用浏览器访问api/v1/pdf接口，或者用Postman测试：

• 如果浏览器/Postman能正常打开PDF，那就是Swagger的配置问题，可以添加对二进制响应的支持：

services.AddSwaggerGen(c => {
    // 其他配置...
    c.MapType<FileStreamResult>(() => new OpenApiSchema {
        Type = "string",
        Format = "binary"
    });
});

4. 检查全局中间件的影响 #

如果你的API配置了全局压缩中间件（比如Gzip），可能会导致PDF流被压缩后没有正确解压，也会出现损坏。可以针对PDF接口禁用压缩：

app.UseWhen(context => !context.Request.Path.StartsWithSegments("/api/v1/pdf"), appBuilder => {
    appBuilder.UseResponseCompression();
});

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