使用mPDF生成PDF在Chrome等浏览器提示加载失败的解决方法

这个报错本质是浏览器收到的响应内容不是合法的PDF二进制流，PDF文件结构被破坏，常见排查修复步骤按优先级排序：

• 排查前置输出污染
  所有在PDF输出之前发送到浏览器的内容，包括PHP文件开头的BOM头、PHP报错/警告/Notice、前置echo的调试内容、文件首尾的空行，都会拼在PDF二进制流的最前面，破坏PDF要求的%PDF-开头的合法文件头。
  验证方法：把下载到本地的损坏PDF用文本编辑器打开，如果第一行不是%PDF-1.x格式的PDF版本标识，就可以确定是输出污染问题。
  你当前代码用了ob_get_clean()获取缓冲区内容，但无法覆盖所有层级的输出，建议在调用$mpdf->Output()前新增ob_end_clean();清空所有未输出的缓冲区内容；同时删除PHP文件末尾的?>闭合标签，避免标签后的空行被当作内容输出。
• 终止Output后的脚本执行
  mPDF的Output()方法会直接输出PDF内容并设置对应响应头，如果方法执行后还有后续PHP逻辑（哪怕是一个空行、一个PHP报错），都会追加在PDF内容末尾导致文件损坏。直接在$mpdf->Output()这行代码后加exit;，强制终止脚本运行，不要执行后续任何逻辑。
• 排查生成阶段的内容错误
  先临时把输出模式改为保存到本地服务器验证：$mpdf->Output('./test_local.pdf','F');，如果服务器本地保存的test_local.pdf也无法打开，说明是生成逻辑本身的问题：
  • 检查pdf.css路径是否正确，file_get_contents()读取失败会返回false，写入mPDF会导致内容结构异常
  • 检查$html变量是否提前定义，你贴的代码里直接调用$mpdf->WriteHTML($html);但没有看到$html的赋值逻辑，未定义变量会触发PHP警告混入内容
  • 删掉冗余的两次iconv转码逻辑：从UTF-8转UTF-8加IGNORE、TRANSLIT参数没有实际转码价值，反而可能在遇到特殊字符时返回异常内容破坏结构
• 排查输出文件名异常
  你当前的文件名直接拼接POST参数，如果参数里包含换行、斜杠、特殊符号，会导致Content-Disposition响应头格式断裂，浏览器无法正确识别响应内容。建议对文件名做非法字符过滤，不要直接拼接用户传入的原始参数。

修复后参考代码 #

<?php
// 确保文件开头没有空行、没有BOM头
$body = ob_get_clean();
// 删掉冗余的iconv转码逻辑

include("mpdf/mpdf.php");
$mpdf=new \mPDF('+aCJK','A4','','' , 35, 0, 0, 0, 0, 0);
$mpdf->SetAutoFont();
$mpdf->autoScriptToLang = true;
$mpdf->autoLangToFont   = true;

$stylesheet = file_get_contents('pdf.css');
$mpdf->WriteHTML($stylesheet,1);
// 提前定义$html变量，避免未定义警告
$mpdf->WriteHTML($html);
$mpdf->WriteHTML($body);

// 过滤文件名非法字符
$filename = preg_replace('/[^\w\-]/', '', $_POST["id"])."_".preg_replace('/[^\w\-]/', '', $_POST["year"]).'.pdf';
// 清空所有前置缓冲区
ob_end_clean();
$mpdf->Output($filename,'D');
// 直接终止脚本，避免后续输出
exit;
// 不要加文件末尾的?>闭合标签，避免尾部空行污染

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