Chrome v79中PDF资源MIME类型警告问题求助

我之前也碰到过Chrome这个有点棘手的警告，结合你的代码和场景，给你几个针对性的排查和解决思路：

1. 避免手动收集Buffer，直接用Pipe输出PDF #

你的代码里是通过收集chunks再concat成Buffer返回，这种手动处理方式有时候会引入隐藏的编码或传输问题。试试直接把pdfDoc的输出pipe到响应对象，这是pdfmake推荐的流式输出方式，更稳定：

router.get('/get-pdf/:filename', async (req, res)=>{
  const PdfPrinter = require('pdfmake');
  // 确保已正确初始化printer（比如传入字体配置）
  const printer = new PdfPrinter(yourFonts);
  const pdfDoc = printer.createPdfKitDocument(docDefinition);

  // 设置响应头
  res.setHeader('Content-Type', 'application/pdf');
  res.setHeader('Content-Disposition', 'inline; filename="'+ req.params.filename +'"');

  // 直接pipe到响应
  pdfDoc.pipe(res);
  pdfDoc.end();
});

2. 尝试用<iframe>替代<object>加载PDF #

Chrome v79对<object>标签加载PDF的解析逻辑有一些特殊处理，换成<iframe>有时候能绕过这个警告：

<iframe src="/get-pdf/filename.pdf" width="100%" height="100%" frameborder="0"></iframe>

3. 检查服务器中间件是否篡改了响应头 #

有些服务器中间件（比如压缩、安全相关的中间件）可能会偷偷修改你的响应头。比如如果启用了X-Content-Type-Options: nosniff，虽然它是强制MIME类型解析，但在老版本Chrome里可能和<object>的加载逻辑冲突，可以暂时禁用这个头测试一下。另外，确认没有其他中间件覆盖了Content-Type的值。

4. 验证生成的PDF文件完整性 #

先把binaryResult保存到本地，用PDF阅读器打开确认文件没有损坏。如果文件本身有问题，Chrome也可能触发这类警告。你可以在本地测试：

const fs = require('fs');
createPdf().then(buffer => {
  fs.writeFileSync('test.pdf', buffer);
});

打开test.pdf确认能正常显示，排除文件本身的问题。

5. 确认请求的Accept头 #

在Chrome开发者工具的Network面板里，查看这个PDF请求的Accept头是否包含application/pdf。如果前端发起的请求Accept头是text/html之类的，Chrome会误解资源类型，但一般<object>设置type="application/pdf"会自动发送正确的Accept头，不过还是确认一下更稳妥。

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