性能基准
本页面呈现 TCPDF-Next 与其他主流 PHP PDF 库（TCPDF、DomPDF、mPDF）的真实性能基准比较。所有数据均来自同一台机器上的 Docker 容器内实测，确保公平、可重现的结果。我们报告中位数而非平均数，以消除离群值干扰。凡 TCPDF-Next 不是最快的场景，我们也如实说明。
测试环境
| 参数 | 数值 |
|---|---|
| CPU | Intel Core i9-13900K (x86-64) |
| 内存 | 64 GB DDR5（Docker 限制 16 GB） |
| Docker | 4 CPUs, 16 GB RAM, Ubuntu bookworm |
| PHP | 8.5.3（CLI，OPcache 启用，JIT 启用） |
| TCPDF-Next | 1.6.0 |
| TCPDF-NextArtisan (Chrome) | 1.0.0 |
| TCPDF | 6.10.1 |
| DomPDF | v3.1.4 |
| mPDF | v8.2.7 |
| 预热 | 3 次迭代（丢弃） |
| 测量 | 20 次迭代（取中位数） |
| 计时方式 | hrtime(true) 纳秒精度挂钟时间 |
TIP
所有基准测试皆为自动化且可重现。基准测试套件位于仓库的 tests/Benchmark/ 目录中，您可在 Docker 环境内自行执行。
交互式比较图表
PHP 8.5.3 + OPcache + JIT · Docker 4 CPUs / 16 GB · i9-13900K · Median of 20 runs
生成速度
每个场景在预热后运行 20 次。下表展示中位数生成时间、峰值内存、输出文件大小与相对速度。
场景一：简单文档（1 页）
一页 A4 文档，包含标题与基本格式化文字。无图片、无表格。
| 库 | 时间（ms） | 峰值内存（MB） | 文件大小（KB） |
|---|---|---|---|
| TCPDF-Next | 0.63 | 4 | 3 |
| TCPDF | 2.50（3.97x 慢） | 12（3.0x） | 7（2.3x） |
| DomPDF | 4.07（6.46x 慢） | 12（3.0x） | 2（0.7x） |
| mPDF | 7.13（11.32x 慢） | 16（4.0x） | 28（9.3x） |
TCPDF-Next 在简单文档场景中以 0.63 ms 的生成时间遥遥领先——比 TCPDF 快近 4 倍、比 DomPDF 快 6.5 倍、比 mPDF 快 11.3 倍。同时峰值内存仅 4 MB，远低于其他库。
场景二：发票（2 页）
两页发票文档，包含表格行项目、合计、页眉与页脚。
| 库 | 时间（ms） | 峰值内存（MB） | 文件大小（KB） |
|---|---|---|---|
| TCPDF | 1.15 | 16 | 9 |
| TCPDF-Next | 1.64 | 16 | 52 |
| DomPDF | 19.09（11.64x 慢于 Next） | 16 | 4 |
| mPDF | 21.66（13.21x 慢于 Next） | 18 | 30 |
诚实说明
在发票场景中，TCPDF 以 1.15 ms 比 TCPDF-Next 的 1.64 ms 快约 1.4 倍。TCPDF 同时产出更小的文件（9 KB vs 52 KB）。这可能是因为 TCPDF 高度优化的传统表格布局引擎在简单表格内容下更为高效。两个库在此场景中仍远超 DomPDF 和 mPDF。我们如实报告所有数据，不做选择性展示。
场景三：100 页报告
100 页文档，内容为密集混合内容：标题、段落与跨多页的结构化数据。
| 库 | 时间（ms） | 峰值内存（MB） | 文件大小（KB） |
|---|---|---|---|
| TCPDF-Next | 32.39 | 18 | 96 |
| TCPDF | 102.47（3.16x 慢） | 18 | 101 |
| mPDF | 1,044.05（32.23x 慢） | 82（4.6x） | 181 |
| DomPDF | 2,705.55（83.53x 慢） | 70（3.9x） | 129 |
100 页场景中 TCPDF-Next 的优势最为显著——以 32.39 ms 完成生成，比 TCPDF 快 3.2 倍，比 mPDF 快 32.2 倍，比 DomPDF 快 83.5 倍。内存使用与 TCPDF 持平，远低于 DomPDF 和 mPDF。这得益于流式输出与高效的内部对象管理。
场景四：HTML 转 PDF（内建解析器）
使用各库内建的 HTML 解析引擎，将包含 CSS 样式、表格、图片与多栏版面的复杂 HTML 文档转换为 PDF。
| 库 | 时间（ms） | 峰值内存（MB） | 文件大小（KB） |
|---|---|---|---|
| TCPDF-Next | 0.93 | 74 | 7 |
| TCPDF | 7.62（8.19x 慢） | 74 | 13 |
| DomPDF | 16.09（17.30x 慢） | 74 | 5 |
| mPDF | 33.62（36.15x 慢） | 74 | 46 |
TCPDF-Next 的 HTML 解析引擎在不到 1 ms 内完成转换——比 TCPDF 快 8.2 倍，比 mPDF 快 36.2 倍。四个库的峰值内存均为 74 MB，表明该场景的内存消耗主要来自 HTML 解析器基础设施本身。
场景五：HTML 转 PDF（Chrome 渲染 —— TCPDF-NextArtisan）
使用 TCPDF-NextArtisan 调用 Chrome 浏览器进行像素级精确的 HTML 渲染，再导入为 PDF。
| 库 | 时间（ms） | 峰值内存（MB） | 文件大小（KB） |
|---|---|---|---|
| TCPDF-NextArtisan (Chrome) | 309.85 | 74 | 37 |
为什么 Chrome 渲染较慢？
Chrome 渲染模式的 309.85 ms 远高于内建解析器的 0.93 ms，这是由以下技术原因决定的：
- Chrome Page 生命周期开销 — 需要与 Chrome 进行多次 CDP（Chrome DevTools Protocol）通信往返，包括页面创建、导航、等待渲染完成等步骤
- printToPDF 本身耗时 — Chrome 的
printToPDF命令本身就需要约 200-300 ms 来完成页面光栅化与 PDF 生成 - PDF 解析与 XObject 导入 — 从 Chrome 获取 PDF 后，还需解析该 PDF 并将页面作为 XObject 导入到 TCPDF-Next 文档中，产生额外开销
- 已启用 BrowserPool keep-alive — 测试中已使用浏览器连接池保持长连接，避免了每次请求都冷启动浏览器的开销
速度与品质的取舍： DomPDF 和 mPDF 的内建 HTML 引擎虽然更快，但 CSS 支持非常有限。TCPDF-NextArtisan 的 Chrome 渲染模式提供像素完美的 CSS3 支持（包括 Flexbox、Grid、自定义字体、媒体查询等），适用于对排版品质有极高要求的场景。当您需要精确还原设计稿或生成视觉高保真的 PDF 时，这额外的 300 ms 是值得的。
吞吐量
在持续工作负载（60 秒测试）中，每秒与每分钟生成的简单文档（1 页）数量。
单线程模式
| 库 | 文档/秒 | 文档/分钟 |
|---|---|---|
| TCPDF-Next | 2,684 | 161,014 |
| TCPDF | 1,244 | 74,626 |
| DomPDF | 260 | 15,588 |
| mPDF | 133 | 7,994 |
4 Workers 并行模式
| 库 | 文档/秒 | 文档/分钟 |
|---|---|---|
| TCPDF-Next | 9,434 | 566,024 |
| TCPDF | 4,431 | 265,832 |
| DomPDF | 939 | 56,334 |
| mPDF | 484 | 29,044 |
TCPDF-Next 在单线程下可达每分钟约 16.1 万份文档；使用 4 个 Worker 并行时，吞吐量提升至每分钟约 56.6 万份文档——约为 TCPDF 的 2.1 倍、DomPDF 的 10.0 倍、mPDF 的 19.5 倍。对于高容量批处理场景（发票生成、报表生成、对账单生成），这些吞吐量数字直接转化为基础设施成本节省。
数字签名开销
新增数字签名时的额外时间与文件大小。其他三个库均不支持 PAdES 高级签名。
| 签名等级 | 额外时间 | 额外文件大小 | 备注 |
|---|---|---|---|
| PAdES B-B | +15 ms | +5-8 KB | 基础签名 |
| PAdES B-T | +120 ms* | +8-12 KB | 含时间戳 |
| PAdES B-LT | +250 ms* | +15-50 KB | 含长期验证数据 |
| PAdES B-LTA | +350 ms* | +20-60 KB | 完整长期归档验证 |
*包含至 TSA/OCSP 服务器的网络往返时间。实际时间取决于服务器延迟与网络状况。
TIP
PAdES B-B（基础签名）仅增加约 15 ms 和 5-8 KB——对大多数工作流程而言可忽略不计。更高等级（B-T、B-LT、B-LTA）的延迟主要来自时间戳授权机构和 OCSP 响应器的网络调用。
| 库 | PAdES 支持 |
|---|---|
| TCPDF-Next | B-B / B-T / B-LT / B-LTA 全等级支持 |
| TCPDF | 仅基础 PKCS#7 |
| DomPDF | 不支持 |
| mPDF | 不支持 |
PDF/A-4 归档开销
生成符合 ISO 19005-4 标准的 PDF/A-4 归档文件时的额外开销。
| 特性 | 额外大小 |
|---|---|
| sRGB ICC 色彩配置文件 | +3 KB |
| XMP 元数据 | +2-5 KB |
| 输出意图 | +1-3 KB |
| 完整字体嵌入（如需） | 每字体 +50-500 KB |
| 典型总开销 | +10-50 KB |
| 生成时间开销 | < 5% |
TIP
PDF/A-4 模式下默认仍使用字体子集化。开销主要来自 ICC 配置文件和扩展的元数据。对于大多数文档，PDF/A-4 开销可忽略不计。
为什么 TCPDF-Next 更快
TCPDF-Next 的性能优势来自以下深思熟虑的架构决策：
现代 PDF 2.0 核心 — 渲染管线从零构建于 PDF 2.0 之上，消除了拖慢 TCPDF 的传统兼容层。交叉引用流与对象流同时减少了 I/O 和文件大小。
JIT 友好的代码路径 — 热循环与关键渲染方法经过特别设计以充分利用 PHP 8 的 JIT 编译器。紧凑、强类型且分支最小化的代码使 JIT 能够生成高效的机器码。
延迟资源加载 — 字体、图片与 ICC 配置文件仅在首次使用时加载，而非在构造时。不嵌入图片的文档无需承担任何图片处理开销。
高效内存布局 — 页面对象经过紧凑处理，通过引用计数复用共享资源（字体、颜色空间），即使在长文档中也能保持低峰值内存。
优化的 HTML 解析器 — 不同于传统 TCPDF 使用的基于正则的 HTML 解析，TCPDF-Next 采用流式令牌化解析器，在单次遍历中处理 HTML，最小化回溯。
可并行化设计 — 无状态的页面渲染架构使工作负载可在多个 Worker 间线性扩展，正如 4 Worker 模式下接近 4 倍吞吐量提升所证明的。
测试方法
基准设计原则
- 隔离 — 每项基准测试在独立的 PHP 进程中执行，消除交叉测试的内存污染
- 预热 — 丢弃前 3 次预热迭代后才开始测量，确保 OPcache 与 JIT 已完全预热
- 迭代 — 每项测试场景 20 次测量迭代。报告中位数以消除离群值噪声
- 计时 —
hrtime(true)提供纳秒精度的挂钟时间测量，避免microtime()的时钟漂移问题 - 内存测量 —
memory_get_peak_usage(true)报告 PHP 运行时实际分配的峰值内存（RSS） - 文件大小 — 输出写入临时文件后以
filesize()测量 - Docker 隔离 — 使用固定资源配置的 Docker 容器（4 CPUs, 16 GB RAM），所有库在同一 Docker 容器内使用相同的 PHP 配置、CPU 限制与内存限制运行
公平性保证
- 四个库均使用各自最新的稳定版本
- 所有库均在相同的 Docker 镜像与 PHP 版本下运行
- OPcache 与 JIT 对所有库统一启用
- 测试文档内容完全相同（相同的文字、图片、表格结构）
- 基准脚本开源，任何人均可审查与重现
重现基准测试
基准测试套件包含在仓库中。要重现这些结果：
cd benchmark
docker compose up --build结果将在运行结束时打印到标准输出。Docker 配置确保无论宿主操作系统如何，环境都是一致的。
TIP
建议在低负载时段执行基准测试，并关闭其他 CPU 密集型应用程序，以获得最稳定的结果。多次运行并对比结果可进一步验证数据的可靠性。
延伸阅读
- 从 TCPDF 迁移 — 分步迁移指南
- 性能调优 — 流式模式、内存优化与缓存策略
- API 参考 — TCPDF-Next 完整 API 文档
- 安全性 — 安全架构与最佳实践
- 示例 — 代码示例与使用范例