php 8.5.5 不直接生成 pdf，失败源于 mpdf v7.x、fpdi 2.3.6 及 tcpdf 6.6.x 等旧库未适配其严格类型检查、废弃函数移除及解析器新规，需升级至 mpdf v8.2+、fpdi 2.6.0+ 或 tcpdf 6.7.0+。
PHP 8.5.5 本身不直接生成 PDF，失败根源在于你用的 PDF 库（如 mPDF、TCPDF、FPDI）尚未适配该版本——尤其是 mPDF v7.x 和多数老版 TCPDF/FPDI 仍停留在 PHP 7.3 兼容层，遇到 PHP 8.5.5 的严格类型检查、废弃函数移除（如 each()）、或反射行为变更时会静默崩溃或抛出 Fatal error。
为什么 mPDF 在 PHP 8.5.5 下直接白屏或报错
mPDF v7.x 已停止维护，其代码中残留的 create_function()、未声明返回类型的回调、以及依赖 mbstring 某些宽松行为的逻辑，在 PHP 8.5.5 中被彻底禁止或改变语义。即使 require_once 成功，new \Mpdf\Mpdf() 构造过程也可能在内部触发致命错误，且因 PDF 输出前 header 已发送而无法显示错误。
- 典型现象：浏览器空白、HTTP 500、或日志里出现
Deprecated: Function create_function() is deprecated（实际在 8.5.5 中已是 Fatal Error） - 验证方式：在脚本开头加
error_reporting(E_ALL); ini_set('display_errors', 1);，再运行——若仍无输出，说明错误发生在输出缓冲启动前 - 解决路径：必须升级到 mPDF v8.2+（官方明确支持 PHP 8.1–8.5），且注意 v8 的字体注册和中文配置与 v7 不同
FPDI 2.3.6 或更早版本无法加载 PDF 的真实原因
FPDI 2.x 基于 PHP 7.2+ 设计，但未覆盖 PHP 8.5 的新限制。常见失败点不是路径或 PDF 文件损坏，而是其内部 Fpdi.php 中的类继承链或 trait 使用方式触犯了 PHP 8.5 的解析器新规——例如未显式声明构造方法参数类型，或 __call() 返回类型缺失。
- 错误表现：
Fatal error: Declaration of Setasign\Fpdi\Fpdi::addPage() must be compatible with FPDF::addPage()类型签名冲突 - 关键动作：改用 FPDI 2.6.0+（2025 年后发布），它已修复 PHP 8.4/8.5 兼容性问题；旧项目请勿硬套
autoload.php路径，应通过 Composer 安装而非手动 require - 验证是否真加载成功：运行
var_dump(class_exists('Setasign\Fpdi\Fpdi'));—— 返回false即说明 autoloading 失败，不是 PDF 本身问题
TCPDF 在 PHP 8.5.5 中中文乱码或崩溃的隐藏条件
TCPDF 6.6.x 是最后一个广泛使用的稳定版，但它默认加载的 dejavusans 字体文件（dejavusans.php）在 PHP 8.5.5 下解析失败——该文件含大量动态变量名拼接，违反了新版引擎对“可变变量”作用域的收紧规则。
- 症状：PDF 生成成功但文字全为空白，或报
Warning: Undefined array key "cw"后终止 - 绕过方案：改用 TCPDF 6.7.0+（2025 年起维护），并强制指定字体路径为绝对路径，避免相对路径触发 autoload 行为异常
- 临时补救：在调用
$pdf->AddFont()前，先执行ini_set('precision', 14);—— PHP 8.5 默认精度提升导致某些浮点计算溢出，间接影响字体度量解析
真正卡住人的地方不在代码写法，而在你根本不知道哪个底层调用在 PHP 8.5.5 里悄悄变了行为。建议用 composer show setasign/fpdi mpdf/mpdf tecnickcom/tcpdf 确认实际安装版本，再对照各库官网的 “Supported PHP versions” 表格——别信 README 里的模糊描述，要看最新 release note 里写的 “tested on PHP 8.5.5”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
